Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.
Аппаратный уровень
Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.
Уровень операционной системы
Вторым пунктом нашей программы стала проверка и настройка операционной системы, суть которой заключается в следующем:
- привести в порядок файловую систему;
- отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
- проверить оптимальность настроек операционной системы.
Под приведением в порядок файловой системы подразумевается самые очевидные операции, которые, как это не странно выглядит, многими администраторами считаются неприменимыми к серверным операционным системам. Речь идет о:
- проверке логической структуры диска;
- удалении временных и ненужных файлов;
- дефрагментации файловой системы.
Справедливости ради, надо заметить, что для SSD-дисков дефргаментация действительно ничего не дает, а только увеличивает количество циклов записи. В моем случае, после приведения файловой системы в порядок сервер немного «ожил», но этого все равно было недостаточно.
Я думаю, не нужно объяснять, зачем нужна антивирусная проверка и отключение неиспользуемых служб, но пренебрегать этим не стоит. Посмотрите, может были установлены какие-то программы, которые сейчас уже не нужны на этом сервере. Ну и сделайте обновление системы и программ.
Что касается оптимальности настроек операционной системы, то в моем случае был выставлен экономный режим электропитания. После включения режима максимальной производительности тест Гилева показывал удовлетворительные результаты, но тот конкретный сервер должен был показывать более высокие результаты.
Для выяснения причин был произведен мониторинг использования ресурсов, хотя с самого начала было понятно, что искать надо те процессы, которые много занимают дисковую подсистему. В моем случае лучшим показателем явился «Длина очереди к диску». Напомню, что остальные показатели были в норме, они конечно немного изменились по сравнению с первоначальными, но в целом индикатором так и осталась длина очереди к диску. Результаты мониторинга были очевидны: «расхитителями» ресурсов оказались процессы сервера 1С и сервера баз данных.
Уровень служб
В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска.
Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.
Уровень баз
Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант.
У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.
Заключение
Если использовать только один уровень для поиска причин низкой производительности, то можно оставить без внимания причины, лежащие на других уровнях, то есть результат будет не достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне. Надеюсь, что данный материал поможет кому-то побороть проблему низкой производительности 1С-сервера.
Комментарии (19)
alex-khv
27.07.2016 16:13+8Какие-то очередные вредные советы.
Зачем на RAID делать дефрагметацию?
Например, возьмем RAID-5, в нем грубо говоря данные А хранятся в 234234 секторе диска 1, данные Б хранятся в секторе 3423423 диска 2, и контрольная сумма данных А и Б хранится в секторе 456456 диска 3.
После дефрагментации, данные А теперь лежат в секторе 789745656 диска 3, данные Б лежат в секторе 1283894 диска 2, и контрольная сумма А и Б хранится в секторе 7521648 диска 1.
После записи 10ГБ на диск, какая будет фрагментация файлов размазанных по трем дискам?
Потом, зачем вставлять неисправный диск в деградированный массив?
Почему не настроен мониторинг raid-контроллера?
Зачем таскать сервер, если это все видно в стойке?
Все эти, проверка логической структуры, проверка на вирусы, дефрагментация, помогут только увеличить часы работы аутсорсеру.
Если 1С сервер тормозит, первое дело открыть диспетчер задач и perfmon. Потом посмотреть какие rphost жрут ресурсы и по proc Id сопоставить с базами. Дальше указать 1Сникам на проблему в конкретной БД.
Лечение большого TLog, вообще эпик.IvnAR
28.07.2016 16:19Не понятен пример с RAID-5.
Для ОС, в которой производится дефрагментация, все три диска разворачиваются в один логический, в котором и происходит упорядочивание логических единиц хранения(кластер, блок...), а не секторов.
Какова бы не была схема размещения данных по дискам RAID5, все равно она строится с учетом, что бы получить максимальную скорость чтения/записи последовательных данных. Поэтому оптимизация сильно дефрагментированных логических дисков все же имеет смысл. Особенности строения современных файловых систем нивелируют фрагментацию, но(исходя из моего опыта) не полностью.alex-khv
29.07.2016 09:45+1Дефрагментация — операция перемещения кластеров одного файла в непрерывную цепочку. Это позволяет уменьшить время позиционирования головки ЖД, что приводит к ускорению операций чтения.
RAID5 — это логический диск. Для ОС, все кластеры (виртуальные) этого логического диска после дефрагментации выстраиваются в одну цепочку.
Но! ОС не видит физических кластеров. А так как RAID-контроллер, в свою очередь, ничего не знает о фрагментации и файлах. То получается что на физическом уровне, данные перезаписываются с одного места на другое.
Потом, SQL Server заранее выделяет место под свой файл кратный своим страницам. Так, чтобы избежать фрагментации.IvnAR
01.08.2016 14:09То у вас оптимизация по секторам идет, то RAID контроллер работает с кластерами… RAID контроллер работает с блоками данных, причем одного размера для всего виртуального диска. Структура RAID5 может быть такой:
(БД-блок данных). Схема чередования, задержка чередования(второй вариант) может отличаться в зависимости от контроллера и настроек виртуального диска.
То, что ОС не видит структуры виртуального диск совершенно не означает, что доступ к фрагментированным данным будет такой же быстрый, как к не фрагментированным! Очевидно же(посмотрев на рисунок) в случае фрагментации на RAID5 просто уменьшается расстояние между фрагментами на физических дисках (в данном примере в два раза).
Вывод: дефрагментация RAID5 — ускоряет доступ к данным.
То, что SQL сервер выделяет место кратно своим страницам, вовсе не означает, что в процессе работы файл базы данных не станет фрагментированным (пример — две базы на одном диске расширяющиеся по очереди).alex-khv
01.08.2016 14:181. Вполне может быть что в первом варианте на уровне логического диска фрагментации нет, а во втором варианте ОС думает что у нее много фрагментированных файлов.
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?IvnAR
01.08.2016 17:081. Вполне может быть что в первом варианте на уровне логического диска фрагментации нет, а во втором варианте ОС думает что у нее много фрагментированных файлов.
Если расстояние между фрагментами меньше (Количество_Дисков — 1)*Размер_Блока, то фактически, фрагментации можно считать что нет, но тут начинает влиять фактор, что для доступа к файлу нужно считать/записать больше блоков данных(т.к. любая фрагментация увеличивает шанс попадания в +1 блок данных). А для RAID 5 это более затратно, т.к. данные(в случае записи) пишутся на два диска и должны прочитаться с третьего(для формирования контрольной суммы по модулю 2).
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?
Как я уже говорил, не фрагментированное расположение данных в ОС залог быстрой работы и RAID. Т.е. данные и будут лежать по порядку, с разрывами по блокам данных RAID. Эти разрывы нивелируются алгоритмами работы RAID(распараллеливанием операций с дисками).
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?
При архивировании/восстановлении, конечно не будет, т.к. задержка позиционирования головки почти не скажется на общем времени операции. Но если взять случайный доступ к базе данных, то там, увеличение времени позиционирования из-за разнесения данных по поверхности, будет сказываться на производительности. Ведь при записи данных в базу, идет реальная запись на диск(правда нивелируемая при при включенном «write back», кэшем контроллера).(Кстати, приращение БД в 1ГБ(в MSSQL), находящейся на одном диске, это многовато, т.к. при расширении, sql должен проинициализировать эту область на диске «0»-ми).
kol_dm_ukk
27.07.2016 19:15Странная публикация, по моему мнению. Ни тебе описания какая конфигурация 1С, размер базы, какая конфигурация сервера, количество пользователей и прочие важные «мелочи». Получилось что-то вроде — «я что-то сделал и оно как-то само заработало».
Jump
28.07.2016 06:04+3Публикация более чем странная.
Проверка оборудования и настройка системы — вещи однозначно очевидные и не имеющие отношения к настройке сервера 1с.
Монитор ресурсов это та вещь с которой стоит начинать разбор полетов с низкой производительностью чего — либо.
теперь 1С-сервер не поддерживает обмен данным через Shared Memory
Если кто-то не смог настроить технологию, это еще не значит что она не работает.
Не могу объяснить почему, но изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере
Если не можете объяснить, зачем же тогда трогать? Загадочного там ничего нет. Количество ИБ на процесс показывает серверу сколько ИБ держать на одном процессе. Если у вас количество одновременно работающих баз меньше количества процессоров, то разумеется лучше выставить единицу, вот когда баз много тогда другое дело.
Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах.
Кто же тестовые задачи гоняет на продакшен сервере?
По этим причинам было решено снять резервные копии баз средствами 1С (dt-файл), после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
А вы однако любите риск! Выгрузка в dt файл не является средством резервного копирования, и может банально не развернуться в случае проблем с базой. Резервные копии перед выгрузкой в dt файл надо создавать средствами SQL.
Основной смысл всей статьи кратко — на сервере творился полный бардак, никто ни за чем не следил, потом пришел хороший человек, сделал что-то, чего он до конца не понимает, и сервер вроде стал работать быстрее.
Очень познавательно!
Kheus
28.07.2016 09:10Это, конечно, из серии вредных советов: использовать один сервер для рабочих баз данных и для разработки.
brainfair
28.07.2016 11:55Нанимать квалифицированных администраторов это так банально, легче же жрать кактусы и потом так же не квалифицированно искать проблему.
Sergey-S-Kovalev
28.07.2016 12:07Выжимка:
Автор, не имея опыта комплексного системного администрирования, рассказывает нам про наколеночные методы поиска и лечения проблем, половина которых являются городскими легендами, одновременно спасая эникейщиков обслуживающих сервер и почему то называет их системными администраторами. Часть вещей сам объяснить не может. Если не может, значит там магия :)
Но я бы с удовольствием посмотрел, как он вынул бы сервер-хост из кластера виртуализации, и проверил в нем нагрузку на дисковую подсистему на системе хранения данных.
compilator
28.07.2016 13:10+1«снять резервные копии баз средствами 1С (dt-файл), после чего удалить 1С-базы из сервера 1С»
Читая это, рядом со мной родилась пара кирпичей. Страшно представить какую стену можно было бы возвести, если бы я делал это осознанно.
7889
28.07.2016 15:12+1Именно такие посты показывают, что каждый должен заниматься своим делом.
1с-ник, возомнивший себя сисадмином — страшная сила.
Настройка M$SQL сервера по теме с infostart.ru особо прослезила.
Про бэкапы порыдал.
А если серьезно, то с таким везением надо было в этот день на рулетку или блэкджек!
yukon39
28.07.2016 16:20+2Техножречество как оно есть. Магические пассы руками, вдумчивое разглядывание диодов на лицевой панели и дефрагментация RAID массива исправили проблемы производительности.
Но, надо отметить, вы весьма удачливы, т.к. любая из этих операций легко могла быть фатальной:
1. Вытащить сервер из стойки.
2. Вставить сбойный диск в RAID
3. Перевыгрузка базы из dt в SQL
gotch
В Perfmon вы не заметили высокую latency и дисковую очередь? И не посмотрели wait types в SQL? Для этого понадобилось физически осматривать сервер?
И про Database Instant File Initialization не слышали?
Вместо этого вы предпочли шаманские «проверка логической структуры диска», «удаление временных и ненужных файлов», «дефрагментация файловой системы».
А залив данные обратно вы, видимо, просто получили полностью дефрагментированные индексы?