Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
В Perfmon вы не заметили высокую latency и дисковую очередь? И не посмотрели wait types в SQL? Для этого понадобилось физически осматривать сервер?
И про Database Instant File Initialization не слышали?
Вместо этого вы предпочли шаманские «проверка логической структуры диска», «удаление временных и ненужных файлов», «дефрагментация файловой системы».
А залив данные обратно вы, видимо, просто получили полностью дефрагментированные индексы?
И про Database Instant File Initialization не слышали?
Вместо этого вы предпочли шаманские «проверка логической структуры диска», «удаление временных и ненужных файлов», «дефрагментация файловой системы».
А залив данные обратно вы, видимо, просто получили полностью дефрагментированные индексы?
Какие-то очередные вредные советы.
Зачем на RAID делать дефрагметацию?
Например, возьмем RAID-5, в нем грубо говоря данные А хранятся в 234234 секторе диска 1, данные Б хранятся в секторе 3423423 диска 2, и контрольная сумма данных А и Б хранится в секторе 456456 диска 3.
После дефрагментации, данные А теперь лежат в секторе 789745656 диска 3, данные Б лежат в секторе 1283894 диска 2, и контрольная сумма А и Б хранится в секторе 7521648 диска 1.
После записи 10ГБ на диск, какая будет фрагментация файлов размазанных по трем дискам?
Потом, зачем вставлять неисправный диск в деградированный массив?
Почему не настроен мониторинг raid-контроллера?
Зачем таскать сервер, если это все видно в стойке?
Все эти, проверка логической структуры, проверка на вирусы, дефрагментация, помогут только увеличить часы работы аутсорсеру.
Если 1С сервер тормозит, первое дело открыть диспетчер задач и perfmon. Потом посмотреть какие rphost жрут ресурсы и по proc Id сопоставить с базами. Дальше указать 1Сникам на проблему в конкретной БД.
Лечение большого TLog, вообще эпик.
Зачем на RAID делать дефрагметацию?
Например, возьмем RAID-5, в нем грубо говоря данные А хранятся в 234234 секторе диска 1, данные Б хранятся в секторе 3423423 диска 2, и контрольная сумма данных А и Б хранится в секторе 456456 диска 3.
После дефрагментации, данные А теперь лежат в секторе 789745656 диска 3, данные Б лежат в секторе 1283894 диска 2, и контрольная сумма А и Б хранится в секторе 7521648 диска 1.
После записи 10ГБ на диск, какая будет фрагментация файлов размазанных по трем дискам?
Потом, зачем вставлять неисправный диск в деградированный массив?
Почему не настроен мониторинг raid-контроллера?
Зачем таскать сервер, если это все видно в стойке?
Все эти, проверка логической структуры, проверка на вирусы, дефрагментация, помогут только увеличить часы работы аутсорсеру.
Если 1С сервер тормозит, первое дело открыть диспетчер задач и perfmon. Потом посмотреть какие rphost жрут ресурсы и по proc Id сопоставить с базами. Дальше указать 1Сникам на проблему в конкретной БД.
Лечение большого TLog, вообще эпик.
Не понятен пример с RAID-5.
Для ОС, в которой производится дефрагментация, все три диска разворачиваются в один логический, в котором и происходит упорядочивание логических единиц хранения(кластер, блок...), а не секторов.
Какова бы не была схема размещения данных по дискам RAID5, все равно она строится с учетом, что бы получить максимальную скорость чтения/записи последовательных данных. Поэтому оптимизация сильно дефрагментированных логических дисков все же имеет смысл. Особенности строения современных файловых систем нивелируют фрагментацию, но(исходя из моего опыта) не полностью.
Для ОС, в которой производится дефрагментация, все три диска разворачиваются в один логический, в котором и происходит упорядочивание логических единиц хранения(кластер, блок...), а не секторов.
Какова бы не была схема размещения данных по дискам RAID5, все равно она строится с учетом, что бы получить максимальную скорость чтения/записи последовательных данных. Поэтому оптимизация сильно дефрагментированных логических дисков все же имеет смысл. Особенности строения современных файловых систем нивелируют фрагментацию, но(исходя из моего опыта) не полностью.
Дефрагментация — операция перемещения кластеров одного файла в непрерывную цепочку. Это позволяет уменьшить время позиционирования головки ЖД, что приводит к ускорению операций чтения.
RAID5 — это логический диск. Для ОС, все кластеры (виртуальные) этого логического диска после дефрагментации выстраиваются в одну цепочку.
Но! ОС не видит физических кластеров. А так как RAID-контроллер, в свою очередь, ничего не знает о фрагментации и файлах. То получается что на физическом уровне, данные перезаписываются с одного места на другое.
Потом, SQL Server заранее выделяет место под свой файл кратный своим страницам. Так, чтобы избежать фрагментации.
RAID5 — это логический диск. Для ОС, все кластеры (виртуальные) этого логического диска после дефрагментации выстраиваются в одну цепочку.
Но! ОС не видит физических кластеров. А так как RAID-контроллер, в свою очередь, ничего не знает о фрагментации и файлах. То получается что на физическом уровне, данные перезаписываются с одного места на другое.
Потом, SQL Server заранее выделяет место под свой файл кратный своим страницам. Так, чтобы избежать фрагментации.
То у вас оптимизация по секторам идет, то RAID контроллер работает с кластерами… RAID контроллер работает с блоками данных, причем одного размера для всего виртуального диска. Структура RAID5 может быть такой:
(БД-блок данных). Схема чередования, задержка чередования(второй вариант) может отличаться в зависимости от контроллера и настроек виртуального диска.
То, что ОС не видит структуры виртуального диск совершенно не означает, что доступ к фрагментированным данным будет такой же быстрый, как к не фрагментированным! Очевидно же(посмотрев на рисунок) в случае фрагментации на RAID5 просто уменьшается расстояние между фрагментами на физических дисках (в данном примере в два раза).
Вывод: дефрагментация RAID5 — ускоряет доступ к данным.
То, что SQL сервер выделяет место кратно своим страницам, вовсе не означает, что в процессе работы файл базы данных не станет фрагментированным (пример — две базы на одном диске расширяющиеся по очереди).
(БД-блок данных). Схема чередования, задержка чередования(второй вариант) может отличаться в зависимости от контроллера и настроек виртуального диска.
То, что ОС не видит структуры виртуального диск совершенно не означает, что доступ к фрагментированным данным будет такой же быстрый, как к не фрагментированным! Очевидно же(посмотрев на рисунок) в случае фрагментации на RAID5 просто уменьшается расстояние между фрагментами на физических дисках (в данном примере в два раза).
Вывод: дефрагментация RAID5 — ускоряет доступ к данным.
То, что SQL сервер выделяет место кратно своим страницам, вовсе не означает, что в процессе работы файл базы данных не станет фрагментированным (пример — две базы на одном диске расширяющиеся по очереди).
1. Вполне может быть что в первом варианте на уровне логического диска фрагментации нет, а во втором варианте ОС думает что у нее много фрагментированных файлов.
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?
1. Вполне может быть что в первом варианте на уровне логического диска фрагментации нет, а во втором варианте ОС думает что у нее много фрагментированных файлов.Если расстояние между фрагментами меньше (Количество_Дисков — 1)*Размер_Блока, то фактически, фрагментации можно считать что нет, но тут начинает влиять фактор, что для доступа к файлу нужно считать/записать больше блоков данных(т.к. любая фрагментация увеличивает шанс попадания в +1 блок данных). А для RAID 5 это более затратно, т.к. данные(в случае записи) пишутся на два диска и должны прочитаться с третьего(для формирования контрольной суммы по модулю 2).
2. Как на уровне виртуального логического диска, положить информацию в физические секторы рядом и по порядку?Как я уже говорил, не фрагментированное расположение данных в ОС залог быстрой работы и RAID. Т.е. данные и будут лежать по порядку, с разрывами по блокам данных RAID. Эти разрывы нивелируются алгоритмами работы RAID(распараллеливанием операций с дисками).
3. Если у нас один физ. диск, и место под файл бд выделили сразу непрерывный кусок 1ГБ, а потом приращениями по 1 ГБ, так ли будет сказываться снижения производительности когда фрагментация файла будет не кусками по 64КБ, а по 1 ГБ?При архивировании/восстановлении, конечно не будет, т.к. задержка позиционирования головки почти не скажется на общем времени операции. Но если взять случайный доступ к базе данных, то там, увеличение времени позиционирования из-за разнесения данных по поверхности, будет сказываться на производительности. Ведь при записи данных в базу, идет реальная запись на диск(правда нивелируемая при при включенном «write back», кэшем контроллера).(Кстати, приращение БД в 1ГБ(в MSSQL), находящейся на одном диске, это многовато, т.к. при расширении, sql должен проинициализировать эту область на диске «0»-ми).
Приветствую! Из рассказа не понятно — все таки. А в чем была причина?
Странная публикация, по моему мнению. Ни тебе описания какая конфигурация 1С, размер базы, какая конфигурация сервера, количество пользователей и прочие важные «мелочи». Получилось что-то вроде — «я что-то сделал и оно как-то само заработало».
Публикация более чем странная.
Проверка оборудования и настройка системы — вещи однозначно очевидные и не имеющие отношения к настройке сервера 1с.
Монитор ресурсов это та вещь с которой стоит начинать разбор полетов с низкой производительностью чего — либо.
Основной смысл всей статьи кратко — на сервере творился полный бардак, никто ни за чем не следил, потом пришел хороший человек, сделал что-то, чего он до конца не понимает, и сервер вроде стал работать быстрее.
Очень познавательно!
Проверка оборудования и настройка системы — вещи однозначно очевидные и не имеющие отношения к настройке сервера 1с.
Монитор ресурсов это та вещь с которой стоит начинать разбор полетов с низкой производительностью чего — либо.
теперь 1С-сервер не поддерживает обмен данным через Shared MemoryЕсли кто-то не смог настроить технологию, это еще не значит что она не работает.
Не могу объяснить почему, но изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервереЕсли не можете объяснить, зачем же тогда трогать? Загадочного там ничего нет. Количество ИБ на процесс показывает серверу сколько ИБ держать на одном процессе. Если у вас количество одновременно работающих баз меньше количества процессоров, то разумеется лучше выставить единицу, вот когда баз много тогда другое дело.
Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах.Кто же тестовые задачи гоняет на продакшен сервере?
По этим причинам было решено снять резервные копии баз средствами 1С (dt-файл), после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.А вы однако любите риск! Выгрузка в dt файл не является средством резервного копирования, и может банально не развернуться в случае проблем с базой. Резервные копии перед выгрузкой в dt файл надо создавать средствами SQL.
Основной смысл всей статьи кратко — на сервере творился полный бардак, никто ни за чем не следил, потом пришел хороший человек, сделал что-то, чего он до конца не понимает, и сервер вроде стал работать быстрее.
Очень познавательно!
Это, конечно, из серии вредных советов: использовать один сервер для рабочих баз данных и для разработки.
Нанимать квалифицированных администраторов это так банально, легче же жрать кактусы и потом так же не квалифицированно искать проблему.
Вот серьезно, каждый раз у меня возникает вопрос — как нанять квалифицированного сотрудника. Всегда готов дать работу человеку, который знает, что делает. На рынке очень много людей, кто-то отсеивается сразу, кто-то вроде что-то знает, но как понять, что его знания действительно принесут результат?
Если вам реально нужен результат от человека, то можно поинтересоваться его результатами на предыдущей работе, все же просто? В плане поиска админа все легче чем прогера, технологий меньше, так же есть курсы и экзамены. Если вам нужен мега квалифицированный эксперт по сиквелу, то в 80% случаев человек с коркой MCSE: Data Platform вам подойдет. Другой вопрос что и стоить такой человек уже будет не 20тр как типо админ студент.
Я бы поспорил «насчет технологий меньше»
Спорить наверно бессмысленно.
imho технологии в энтерпрайзе более статичны, «взрослее» и как правило описаны RFC, отсюда и их меньшее количество, в отличии от программирования, где «каждый день» новый фреймворк, версия или вообще язык программирования…
imho технологии в энтерпрайзе более статичны, «взрослее» и как правило описаны RFC, отсюда и их меньшее количество, в отличии от программирования, где «каждый день» новый фреймворк, версия или вообще язык программирования…
«Каждый день» выходят новые версии софта, которые меняют логику на 180 градусов. Новые апдейты ломают то, чего не должны были сломать. Открывается новая дыра в софте. Это я про новое.
А вообще разделы: ОС, виртуализация, сети, безопасность, системы хранения данных, СУБД, VoIP, железо. Очень огромны. Абстракции в них не менее сложны, чем сам софт. Давно нельзя знать все это сразу.
Средний руки админ использует в два-три раза больше технологий и абстракций, чем средний программист.
Full stack админов намного больше, чем javascript — full stack программистов.
Эникей не админ.
А вообще разделы: ОС, виртуализация, сети, безопасность, системы хранения данных, СУБД, VoIP, железо. Очень огромны. Абстракции в них не менее сложны, чем сам софт. Давно нельзя знать все это сразу.
Средний руки админ использует в два-три раза больше технологий и абстракций, чем средний программист.
Full stack админов намного больше, чем javascript — full stack программистов.
Эникей не админ.
Выжимка:
Автор, не имея опыта комплексного системного администрирования, рассказывает нам про наколеночные методы поиска и лечения проблем, половина которых являются городскими легендами, одновременно спасая эникейщиков обслуживающих сервер и почему то называет их системными администраторами. Часть вещей сам объяснить не может. Если не может, значит там магия :)
Но я бы с удовольствием посмотрел, как он вынул бы сервер-хост из кластера виртуализации, и проверил в нем нагрузку на дисковую подсистему на системе хранения данных.
Автор, не имея опыта комплексного системного администрирования, рассказывает нам про наколеночные методы поиска и лечения проблем, половина которых являются городскими легендами, одновременно спасая эникейщиков обслуживающих сервер и почему то называет их системными администраторами. Часть вещей сам объяснить не может. Если не может, значит там магия :)
Но я бы с удовольствием посмотрел, как он вынул бы сервер-хост из кластера виртуализации, и проверил в нем нагрузку на дисковую подсистему на системе хранения данных.
«снять резервные копии баз средствами 1С (dt-файл), после чего удалить 1С-базы из сервера 1С»
Читая это, рядом со мной родилась пара кирпичей. Страшно представить какую стену можно было бы возвести, если бы я делал это осознанно.
Читая это, рядом со мной родилась пара кирпичей. Страшно представить какую стену можно было бы возвести, если бы я делал это осознанно.
Именно такие посты показывают, что каждый должен заниматься своим делом.
1с-ник, возомнивший себя сисадмином — страшная сила.
Настройка M$SQL сервера по теме с infostart.ru особо прослезила.
Про бэкапы порыдал.
А если серьезно, то с таким везением надо было в этот день на рулетку или блэкджек!
1с-ник, возомнивший себя сисадмином — страшная сила.
Настройка M$SQL сервера по теме с infostart.ru особо прослезила.
Про бэкапы порыдал.
А если серьезно, то с таким везением надо было в этот день на рулетку или блэкджек!
Техножречество как оно есть. Магические пассы руками, вдумчивое разглядывание диодов на лицевой панели и дефрагментация RAID массива исправили проблемы производительности.
Но, надо отметить, вы весьма удачливы, т.к. любая из этих операций легко могла быть фатальной:
1. Вытащить сервер из стойки.
2. Вставить сбойный диск в RAID
3. Перевыгрузка базы из dt в SQL
Но, надо отметить, вы весьма удачливы, т.к. любая из этих операций легко могла быть фатальной:
1. Вытащить сервер из стойки.
2. Вставить сбойный диск в RAID
3. Перевыгрузка базы из dt в SQL
Вангую что ещё и диски sata/nl-sas? :)
Центнеры оперативки, кучи ядер, SSD, окропление святой водой — ничего не помогает, если программный код не оптимален.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методика поиска причин низкой производительности сервера 1с