Я буду рассматривать только возможные причины низкой скорости в клиент-серверном варианте работы 1С.
Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить.
Я буду рассматривать только возможные причины низкой скорости в клиент-серверном варианте работы 1С.
Необходима отдельная и тщательная настройка: дисков, базы данных, операционной системы, кластера 1С.
Необходимо понимать: как работает ваша конфигурация, какое железо лучше использовать, какую платформу 1С использовать, как оптимизировать базу данных
В следующих статьях будем рассматиривать другие причины, коих вечественное множество.
П.С. эта статья – полный бред сумасшедшего и не стоит ей верить.
Диски
Показатели производительности в дисках это комплекс настроек/конфигураций/инсталляций и железа: скорость дисков, объем дисков, наличие RAID-массива, наличие внешней СХД, тип RAID-контроллера, наличие SSD для кэша чтения.
Скорость дисков и их настройка
Определите для начала скорость ваших дисков которые вы используете и посмотрите как разбиты кластеры в них.
Пример №1
В данном случае мы неэффективно используем разбивку количества байт на один кластер и если хранить файлы баз данных на диске D то не мечтайте о быстрой записи данных в базу SQL из 1С:
Делается это при форматировании диска:
З.Ы. Выставив размер кластера = 64кб получим прирост рандомной записи 512кб минимум в 5-10 раз!
Заметка!
При форматировании дисков – выставлять количество байт на один сектор исходя из обязанностей работы ваших дисков.
Пример №2
Disk C+D = 6 SAS 15K в RAID-50
Disk E = 2 СХД по 8 SATA в RAID-50
Диски C и D – использовать под хранение БД категорически не рекомендуется, диск Е – идеальный.
Скорость дисков можно судить по скринам выше, всё на лицо.
Заметка!
Если файлы обменов в РИБ занимают более 50 мегабайт, имеет смысл изменить переменную окружения %temp% пользователя под которым производится обмен, т.к. запись файлов будет вестись быстрее на более быстрых винтах, но не стоит забывать, что производительность записи данных в файл зависит от конфигурации 1С.
Заметка!
На дисках с файлами баз данных не нужно хранить ничего, чтобы не вызывать лишние операции чтения/записи данных на диск дабы не уменьшать производительность.
При настройке RAID-массива(http://ru.wikipedia.org/wiki/RAID) в любом случае мы за что-то платим: скорость, объем или надежность, т.е. как минимум один из трех параметров у нас низкий.
Upd 27.05.2013
При количестве активных пользователей более 100, рекомендуется сделать отдельный RAID-0 массив(не более 10 гб), для хранения на нём файлов: tempdb.mdf и templog.ldf
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
спасибо большое за данный материал, а для файлового варианта можно что-то подобное сделать, было бы очень интересно почитать на эту тему
(1) TrinitronOTV, после более-менее подробного описания всех аспектов и ключевых точек — возможно.
интересный материал, но очень поверхностный.
Не хватает описания методики определения оптимального размера кластера.
По крайней мере из прикрепленных рисунков не понятно почему 64кб размер даст прирост рандомной записи в 5-10 раз, если тестируется последовательное чтение/запись (наверное 4092кб) и рандомная блоков по 512,4кб. Без знания особенности работы СУБД с диском опять же этот тест будет абстрактным.
В любом случае не хватает конечных цифр по работе тестируемой базы 1С при однотипных операциях.
«В данном случае мы неэффективно используем разбивку количества байт на один кластер и если хранить файлы баз данных на диске D то не мечтайте о быстрой записи данных в базу SQL из 1С:»
это по сравнению с диском C? или в принципе?
(2) вот за это большое спасибо, буду ждать с нетерпением…
(0)
Дисклеймер порадовал 🙂
«П.С. эта статья – полный бред сумасшедшего и не стоит ей верить.»
заголовок ввёл в ступор
«Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить.»
существующую у нас систему строил не я, но поддерживать мне.
просто обратил внимание на замечания, размер кластеров не уменьшишь уже, но по крайней мере не хранить с БД всяких хлам, это предпримем 🙂
(1) TrinitronOTV, файловый… даже не знаю.
ИМХО, там все плоско и зависит от дисковой системы — на 100% и скорости доступа по сети.
Остальное… Дифрагментация дифрагентация и т.д
бред сумашедшего, делайте кластеры в 64 к. поменьше такого бы мусора на инфостарте
Что-то я не пойму, на скриншоте с fsutil в чем отличия?
К тому же в результатах тестов отчетливо прослеживается влияние кэширования на запись.
Далее, CrystalDiskMark не имеет режимов тестирования, даже отдаленно похожих на работу СУБД.
Статья ни о чем, выводы сделаны некорректные.
Скорость работы HDD — далеко не самый решающий фактор в скорости работы 1С. Скорость работы RAM и ее объем гораздо сильнее влияют.
Чтобы увеличить полезность статьи рекомендую все же привести замеры производительности 1С
в случае правильного и не правильного размещения базы.
Если честно, проблемы низкой производительности SQL в жестких дисках искал бы в последнюю очередь.
«Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить.»
Рекурсия, однако 🙂
выделил 7 гиг в оперативной памяти с помощью программы RAM Drive.
tempdb.mdf и templog.ldf храню на этом разделе, и логи 1с тоже на этом диске
проблема с нагрузкой на винтах ушла
(0) при работе более 100 пользователей … выделить объем в 10 гигов для темп дб, хм, у меня темп дб весит около 50гигов, и сама база — в разы больше 🙂
Может вы таки привяжитесь не к количеству пользователей?
то отношение общего времени выгрузки всего файла к времени записи его на диск — говорит о бесполезности данных действий, тем более что 1с пишет его кусками.
Здравствуй КЭП!
Скорость дисков можно судить по скринам выше, всё на лицо.
Ага, а так же то, что диск Е заполнен на 3.6Тб, так что там помимо базы — будет крутится куча Г, что противоречит вашему предыдущему высказыванию.
К тому же- зачем хранить файлы в скуле? для этого используется отдельный ссд диск, или рейд из них.
Вообщем извините, но статься реально — НИ О ЧЕМ.
(9) asved.ru,
для просмотра как разбиты сектора
в данном контексте статьи я смотрю только на Диски
(10) ZLENKO.PRO, я знаю, опишу позже
(11) CnupT,
напрасно
(12) bulpi, придумывал долго определение
(13) SergDi, об этом я планировал описать в статье про оперативную память
(14) DitriX,
согласен, нужно смотреть реальные текущие размеры темп баз скуля и скорее всего делать раздел раза в 2-3 больше от текущего. Но тут опять же, если позволяет оперативная память, можно и рам-диск (13) положить его
на этот объем только баз скуля, больше данных на диске том нет. в реальности:
— 2 тб — это базы
— 1,5тб не почищенные логи транзаций этих баз.
Тогда не понятно, с чего вы взяли рекомендацию бить кластеры на 64кб? Разбивка-то одинаковая.
(15) я надеюсь вы не собираетесь публиковать «цикл» статей? А дополните текущую достаточным уровнем информации, для того что бы она логически была завершена.
А то уже кумарят это псевдо циклы.
в этой статье хорошо описано про 64к — http://www.gilev.ru/diskpart. после прочтения вопросов не должно возникнуть. Автор, тема про 64к. не раскрыта.