Тормозит 1С (MS SQL). Как диагностировать?
 

Здравствуйте.

Имеется сеть из 25 компьютеров, одновременно работающих с 1С. Выделенный сервер Win2003 на Xeon E5410 2.53 Ghz, 16 Gb Ram, SCSI диски, сетевой интерфейс на сервере 1 Gbit/s подключен к пассивному свитчу D-Link с 2-я гигабитными портами. Остальные клиенты подключены в этот же свитч к 100 Mbit-ным портам. База MS SQL, серверная и клиентская программы 1С работают на сервере. Папка с клиентской частью общая. Пользователи на рабочих станциях запускают программу из общей папки. Также сервер используется как сервер терминалов для работы 3-х пользователей.

На одном из серверов сети установлена система мониторинга Cacti. Средняя загрузка сервера с 1С в принципе не большая: загрузка всех 8-и ядер в среднем составляет 10-15% иногда подскакивает до 30-30%. Сеть в среднем загружена на 10 Mbit/s во время начала работы в 9-00 загрузка сети возрастает до 30 Mbit/s. Меня немного смущает загрузка оперативной памяти: если перезагрузить сервер то из всей RAM используется только 8 ГБ. После 2-х недель непрерывной работы, оперативка забивается на 12-15 ГБ. Причём основные потребители это sqlserver.exe = 3.5 Гб и несколько процессов rphost.exe*32 = 7 Гб.

Практически все пользователи в основном утром жалуются на "тормоза программы". Я не работаю в 1С и не представляю что там может тормозить. Но они говорят что медленно проводятся документы и делаются какие-то выборки... Корреляции тормозов системы с системными ресурсами я не замечал.

Подскажите пожалуйста в какую сторону копать? Где могут быть слабые стороны системы? Как можно проверить скорость текущего обмена с жёсткими дисками?

P.S. Будут интересны любые мнения.

Tonny_Bennet, сталкивался с таким. Единственное у меня все на разных серверах, .т.е. терминальный, sql и 1с - это три разных сервера. Обошел,через еженочный рестарт служб SqlServerAgent, MsSqlServer и 1C:Enterprise 8.2 Server Agent.
Если надо могу привести скрипты.

Tonny_Bennet,
В SQL ограничьте выделение оперативной памяти. "Тормозить" 1С (кстати, Вы не указали версию) из-за одновременного составления "тяжелых" отчетов и т.п., а также (в 99% случаев) - из-за кривизны написания самих процедур отчетов.

molodoipon, в принципе если не сложно то выложите скрипты... не мне так кому-нибудь другому понадобятся.

monkkey, если не сложно скажите где именно в SQL ограничевается выделение оперативной памяти? Для чего это нужно? И не ухудшит ли это ситуацию?

На сервере по-моему крутится 2 версии 8.1 Enterprise и 8.2.

Дописыванием базы занимается приходящий программист и насколько "кривые" у него скрипты я судить не могу...

P.S. Достаточно серьёзно занимался программированием на С#, и когда один мой знакомый кодер узнал что код в 1С пишется на кирилице - ругался благим матом и говорил ,что в жизни писать под него не станет!!!

Думаю это предрассудки....

там есть и латинский вариант, rtfm :)

Tonny_Bennet
рестарт 1С
рестарт SQL

ограничьте SQL 6 гигами памяти.

Тормоза у вас оттого что у него непомерный аппетит и он читает с диска т.е. из файла подкачки.

Tonny_Bennet, в целях погружения в тему производительности 1С рекомендую Вам сайт Гилев - там много интересного.

На что стоит обратить внимание с ходу:
- по опыту - службу 1С я перезапускал еженедельно по ночам (т.к. она непомерно начинает транжирить память) через скрипт, который сначала запускал start net stop, затем ждал 10 минут и taskkill все rphost оставшиеся в памяти... далее net start;
- Вы не указали тип RAID на сервере... если у Вас RAID5 - то это тормоз для Вашей SQL базы;
- дефрагментируйте диски... некоторые умельцы настраивают прирост базы SQL по 1Мб или 1%... в результате у них вся база фрагментирована; проведите shrink mdf-файла.
- если у Вас на рабочем сервере висит еще пара баз, которые используются для тестов и прочих дел - это нехорошо для производительности;
- общая загрузка CPU в 20-30% ни о чем не говорит - смотрите есть ли процессы, которые полностью занимают ядра процессоров.

При подключении 1С сервера к базе SQL в качестве адреса следует использовать "localhost" - в этом случае обмен идет через память, а не стек TCP\IP.

PS: для теста попробуйте терминально запустить 1С клиента на сервере и сравнить производительность.
PS2: пассивный коммутатор Dlink - однозначно вызывает подозрения в производительности сети.

Отдал под MS SQL 6 ГБайт оперативки. Отрубил использование файла подкачки.

По поводу RAID толком ничего сказать не могу. Операционку и настройку самого сервера делал предыдущий администратор. Винда показывает 2 физических диска на которых размечены 2 логических тома. База и система разнесены на разные диски. Сам сервер достаточно далеко, так что внутрь влезь смогу только при крайней необходимости.... думаю там RAID-0 или вовсе никакого RAID нет. (не ругайтесь сам понимаю что это косяк)

Дефрагметировал диск с базой (было 40% фрагметированных файлов)

Поясните пожалуйста о чём речь? Я не понял.

Т.к. компания представляет собой небольшой холдинг из нескольких юридических лиц. На сервере есть несколько больших баз типа Торговли, Бухгалтерии, Склада... запускается пару копий для тестов и разработки скриптов программистом.

Как проследить какие процессы занимают ядра процессоров?

Проверить к чему обращается 1С при работе с MS SQL (к localhost или к servername) я не смог т.к. без пароля к настройкам базы не достучаться. Пароль поставил приходящий администратор. Запустил мониторинг loopback интерфейса. За сегодняшний день трафика на loopback интерфейсе не было. Может ли это означать что обращение идёт через tcp/ip?

Отключил ненужные роли сервера (dns, wins).

Сегодня проблем с скоростью работы базы не было т.к. на выходных сервер перезагрузил.

zero55, Вот такой коммутатор http://www.dlink.ru/ru/products/3/690.html

Tonny_Bennet, коммутатор не самый плохой.
Нет, т.к. при задании адреса SQL базы "localhost" подключение идет без TCP\IP (что и повышает быстродействие).

Если на сервере стоит приложение от RAID, то оно покажет тип RAID.
Если никакого резервирования (отказоустойчивости) нет, то ругать Вас будет Ваше начальство...

Если у Вас в системе видно 4 лоческих процессора, то любой процесс, стабильно (в течение 10 и более секунд) потребляющий 25% (=1/4) CPU - потенциальный источник узкого места (по процессору). Есть еще узкое место по ОЗУ и жесткому диску.
Для оценки нагрузки процесса на диск и ОЗУ - смотрите утилиту procexp (из комплекта sysinternals).

В настройках конкретной базы SQL указан параметр прироста = 1Мб, т.к. файл базы наращивается по 1Мб - это приводит к сильной фрагментации.
Shrink - стандартная процедура обслуживания SQL базы.

Требования ОЗУ для SQL под 1С определяются объемом баз (и справочниками) и определяются в основном практическим путем, чтобы оптимальный объем данных (в разумных пределах) попадал в кеш сервера. Понятно, что SQL очень лоялен к прочим процессам и может уступать память "заржавшемуся" rphost.

Это не хорошо, т.к. приводит к "захламлению" кеша SQL и 1С-сервера левыми данными неинтересными рабочим базам - это сильно снижает производительность; проблема как правило успешно решается приобретением оотдельной рабочей станции на базе i5 с 4 ядрами + 4-8 Гб ОЗУ - разработчики счастливы, т.к. на этой машине их базы летают быстрее, чем на сервере.
Для оптимизации нагрузки, тестовые SQL-базы можно перевести в bulk recovery mode - это немного снизит нагрузку на SQL.

PS: сайт Гилева я Вам не зря рекомендовал.
PS2: PerfMon никто не отменял - начинайте с него и ищите узкое место.

Приложения от RAID не нашёл. Возможно RAID настроен через BIOS тогда по идее не будет видно что он есть...

Поставил себе утилиту procexp. Очень полезная штука. У меня видно 8 логических процессов и в принципе ни на одном из них загрузка не поднимается более 15% (думаю после перезагрузки системы на выходных нужно будет как минимум неделя чтобы начались тормоза)

Прочитал про Shrink. Решил проверить насколько поможет эта процедура одной из тестовых баз (загружать основную базу побочными операциями в рабочее время не рискнул). Процедура в процессе выполнения уже более часа. Размер базы около 10 Гб. Жду...

По поводу прироста: в настройках *mdf файла указано Autogrowth: By 1 MB, unrestricted growth; в настройках *.log фала Autogrowth: By 10 percent, restricted growth to 2095172 MB. Стоит ли увеличивать размер прироста базы чтобы избежать фрагментации? На сколько? Как сильно это приведёт к разрастанию базы?

Просто я так понимаю придётся копировать бекап базы (порядка 10 ГБ) на этот комп и там подгружать в MS SQL. Думаю это будет достаточно долго.... Или есть какие-нибудь другие варианты работы?

Думаю нужно будет обсудить с программистом. Ибо мне пока страшновато что-то кординально изменять в настройках сервера.

Мне многие его советовали. Я кое-какие рекомендации по настройке MS SQL проделал. Просто там иногда достаточно сложно загнуто как мне кажется. А здесь есть обратная связь и хоть какой то разбор текущей проблемной ситуации...

Посмотрите как в диспетчере устройств называются Ваши накопители.

Мониторить нужно процессы, а не процессоры. Если процесс потребляет более 12% - открывайте его свойства - вкладка Threads - если потребление процессора идет одним потоком - то это узкое место по процессору.

Autogrouth mdf можно задать хотя бы 20% того объема, что у Вас освободится от shrink.
К разрастанию базы это приведет несущественно, т.к. расти она будет в том же темпе, просто скачков будет меньше, но будут они больше.

А как у Вас тестовая база формировалась ранее? Все зависит от постановки задачи: что из себя представляет тестовая база.
Можно, например, в ночное время запускать одностороннюю репликацию с основного на тестовый сервер. А можно как Вы предложили - ночью скриптом выгрузить и загрузить базу.

Если сообщение показалось Вам полезным, то есть хорошая традиция отмечать его.

Tonny_Bennet, о коммутаторе -
Производительность

Коммутационная матрица
13,6 Гбит/с - и это 50 Гигабитных портов? Для агрессивных нагрузок очень плохой вариант, по-мониторьте сеть на битые пакеты, можно просто при большой загрузке посмотреть на компах жалующихся - статистику сети командой netstat -e, в нормальной сети будет как-то так:, если при миллионе преданных пакетов у вас до 100 ошибок - это терпимо, отброшенные говорят о плохой сетевой карте - не справляется или неправильно настроена.

нет, это 48 портов по 100 Мбит/с и 2 порта по 1 Гбит/с

Присмотритесь внимательнее DES-1050G

по поводу ошибок сети: обязательно приму на заметку. Спасибо

1С сам по себе может тормозить нещадно...

Надо смотреть начиная с клиента
1. процессор
2. память
3. диски

На сервере
1. процессор
2. память
3. диски

Посмотрите чтение запись в файлы данных и файлы логов.
1. какая версия SQL
2. какая конфигурация файлов данных
3. установлена ли опция AUTOSHRINK

а сколько бы вы порекомендовали оперативной памяти на сервер SQL 2008 R2, размер базы 80гб, 4х ядерный XEON 2,99ггц, диски 6шт в рейде 10. 2000й летал, 2008 подтормаживает.