gifts2017

Производительность 1С. Клиент-Серверный вариант.

Опубликовал Станислав Чернов (uinx) в раздел Администрирование - Оптимизация БД (HighLoad)

Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить.
Я буду рассматривать только возможные причины низкой скорости в клиент-серверном варианте работы 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


См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Лыткин (TrinitronOTV) 24.05.13 08:28
спасибо большое за данный материал, а для файлового варианта можно что-то подобное сделать, было бы очень интересно почитать на эту тему
2. Станислав Чернов (uinx) 24.05.13 09:01
(1) TrinitronOTV, после более-менее подробного описания всех аспектов и ключевых точек - возможно.
3. Константин - (Kosstikk) 24.05.13 10:29
интересный материал, но очень поверхностный.

Не хватает описания методики определения оптимального размера кластера.
По крайней мере из прикрепленных рисунков не понятно почему 64кб размер даст прирост рандомной записи в 5-10 раз, если тестируется последовательное чтение/запись (наверное 4092кб) и рандомная блоков по 512,4кб. Без знания особенности работы СУБД с диском опять же этот тест будет абстрактным.

В любом случае не хватает конечных цифр по работе тестируемой базы 1С при однотипных операциях.

"В данном случае мы неэффективно используем разбивку количества байт на один кластер и если хранить файлы баз данных на диске D то не мечтайте о быстрой записи данных в базу SQL из 1С:"

это по сравнению с диском C? или в принципе?
serg1974; +1 Ответить
4. Александр Лыткин (TrinitronOTV) 24.05.13 13:33
(2) uinx, вот за это большое спасибо, буду ждать с нетерпением...
5. Vladimir K (KroVladS) 24.05.13 16:41
(0)
Дисклеймер порадовал :)
"П.С. эта статья – полный бред сумасшедшего и не стоит ей верить."

заголовок ввёл в ступор
"Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить."
6. invalid (нормальный такой) 24.05.13 17:48
существующую у нас систему строил не я, но поддерживать мне.
просто обратил внимание на замечания, размер кластеров не уменьшишь уже, но по крайней мере не хранить с БД всяких хлам, это предпримем :)
7. invalid (нормальный такой) 24.05.13 17:50
(1) TrinitronOTV, файловый... даже не знаю.
ИМХО, там все плоско и зависит от дисковой системы - на 100% и скорости доступа по сети.
Остальное... Дифрагментация дифрагентация и т.д
8. John Smith (PiccaHut001) 24.05.13 17:53
бред сумашедшего, делайте кластеры в 64 к. поменьше такого бы мусора на инфостарте
9. Антон Стеклов (asved.ru) 29.05.13 05:10
Что-то я не пойму, на скриншоте с fsutil в чем отличия?

К тому же в результатах тестов отчетливо прослеживается влияние кэширования на запись.

Далее, CrystalDiskMark не имеет режимов тестирования, даже отдаленно похожих на работу СУБД.

Статья ни о чем, выводы сделаны некорректные.
10. ZLENKO.PRO (ZLENKO) 29.05.13 11:04
Скорость работы HDD - далеко не самый решающий фактор в скорости работы 1С. Скорость работы RAM и ее объем гораздо сильнее влияют.
Zircool; sanfoto; CatMix; +3 Ответить 1
11. Алексей Масалыгин (CnupT) 29.05.13 13:03
Чтобы увеличить полезность статьи рекомендую все же привести замеры производительности 1С
в случае правильного и не правильного размещения базы.

Если честно, проблемы низкой производительности SQL в жестких дисках искал бы в последнюю очередь.
12. bulpi bulpi (bulpi) 29.05.13 14:03
"Производительность 1С – это комплекс мероприятий которые необходимо выполнить, для того чтобы её получить."

Рекурсия, однако :)
13. Serg Kondrasgov (SergDi) 29.05.13 16:59
выделил 7 гиг в оперативной памяти с помощью программы RAM Drive.
tempdb.mdf и templog.ldf храню на этом разделе, и логи 1с тоже на этом диске
проблема с нагрузкой на винтах ушла
14. Дмитрий Шерстобитов (DitriX) 29.05.13 17:29
(0) при работе более 100 пользователей ... выделить объем в 10 гигов для темп дб, хм, у меня темп дб весит около 50гигов, и сама база - в разы больше :)

Может вы таки привяжитесь не к количеству пользователей?

Если файлы обменов в РИБ занимают более 50 мегабайт

то отношение общего времени выгрузки всего файла к времени записи его на диск - говорит о бесполезности данных действий, тем более что 1с пишет его кусками.

На дисках с файлами баз данных не нужно хранить ничего, чтобы не вызывать лишние операции чтения/записи данных на диск дабы не уменьшать производительность.

Здравствуй КЭП!

Диски C и D – использовать под хранение БД категорически не рекомендуется, диск Е – идеальный.

Скорость дисков можно судить по скринам выше, всё на лицо.

Ага, а так же то, что диск Е заполнен на 3.6Тб, так что там помимо базы - будет крутится куча Г, что противоречит вашему предыдущему высказыванию.

К тому же- зачем хранить файлы в скуле? для этого используется отдельный ссд диск, или рейд из них.

Вообщем извините, но статься реально - НИ О ЧЕМ.
15. Станислав Чернов (uinx) 30.05.13 01:25
(9) asved.ru,
Что-то я не пойму, на скриншоте с fsutil в чем отличия?
для просмотра как разбиты сектора
Далее, CrystalDiskMark не имеет режимов тестирования, даже отдаленно похожих на работу СУБД
в данном контексте статьи я смотрю только на Диски

(10) ZLENKO.PRO, я знаю, опишу позже

(11) CnupT,
Если честно, проблемы низкой производительности SQL в жестких дисках искал бы в последнюю очередь.
напрасно

(12) bulpi, придумывал долго определение

(13) SergDi, об этом я планировал описать в статье про оперативную память

(14) DitriX,
Может вы таки привяжитесь не к количеству пользователей?
согласен, нужно смотреть реальные текущие размеры темп баз скуля и скорее всего делать раздел раза в 2-3 больше от текущего. Но тут опять же, если позволяет оперативная память, можно и рам-диск (13) положить его
Ага, а так же то, что диск Е заполнен на 3.6Тб, так что там помимо базы - будет крутится куча Г, что противоречит вашему предыдущему высказыванию.
на этот объем только баз скуля, больше данных на диске том нет. в реальности:
- 2 тб - это базы
- 1,5тб не почищенные логи транзаций этих баз.
16. Антон Стеклов (asved.ru) 30.05.13 07:41
для просмотра как разбиты сектора


Тогда не понятно, с чего вы взяли рекомендацию бить кластеры на 64кб? Разбивка-то одинаковая.
17. Дмитрий Шерстобитов (DitriX) 30.05.13 12:05
(15) я надеюсь вы не собираетесь публиковать "цикл" статей? А дополните текущую достаточным уровнем информации, для того что бы она логически была завершена.
А то уже кумарят это псевдо циклы.
18. dan dan (eda) 31.05.13 10:08
в этой статье хорошо описано про 64к - www.gilev.ru/diskpart. после прочтения вопросов не должно возникнуть. Автор, тема про 64к. не раскрыта.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа