Tonny_Bennet, коммутатор не самый плохой.
Цитата Tonny_Bennet:
|
Запустил мониторинг loopback интерфейса. За сегодняшний день трафика на loopback интерфейсе не было. Может ли это означать что обращение идёт через tcp/ip? »
|
Нет, т.к. при задании адреса SQL базы "localhost" подключение идет
без TCP\IP (что и повышает быстродействие).
Цитата Tonny_Bennet:
|
Сам сервер достаточно далеко, так что внутрь влезь смогу только при крайней необходимости.... думаю там RAID-0 или вовсе никакого RAID нет. »
|
Если на сервере стоит приложение от RAID, то оно покажет тип RAID.
Если никакого резервирования (отказоустойчивости) нет, то ругать Вас будет Ваше начальство...
Цитата Tonny_Bennet:
|
Как проследить какие процессы занимают ядра процессоров? »
|
Если у Вас в системе видно 4 лоческих процессора, то любой процесс, стабильно (в течение 10 и более секунд) потребляющий 25% (=1/4) CPU - потенциальный источник узкого места (по процессору). Есть еще узкое место по ОЗУ и жесткому диску.
Для оценки нагрузки процесса на диск и ОЗУ - смотрите утилиту procexp (из комплекта sysinternals).
Цитата Tonny_Bennet:
Цитата QRS: некоторые умельцы настраивают прирост базы SQL по 1Мб или 1%... в результате у них вся база фрагментирована; проведите shrink mdf-файла. »
Поясните пожалуйста о чём речь? Я не понял. »
|
В настройках конкретной базы SQL указан параметр прироста = 1Мб, т.к. файл базы наращивается по 1Мб - это приводит к сильной фрагментации.
Shrink - стандартная процедура обслуживания SQL базы.
Цитата Tonny_Bennet:
|
Отдал под MS SQL 6 ГБайт оперативки. Отрубил использование файла подкачки. »
|
Требования ОЗУ для SQL под 1С определяются объемом баз (и справочниками) и определяются в основном практическим путем, чтобы оптимальный объем данных (в разумных пределах) попадал в кеш сервера. Понятно, что SQL очень лоялен к прочим процессам и может уступать память "заржавшемуся" rphost.
Цитата Tonny_Bennet:
|
запускается пару копий для тестов и разработки скриптов программистом. »
|
Это не хорошо, т.к. приводит к "захламлению" кеша SQL и 1С-сервера левыми данными неинтересными рабочим базам - это сильно снижает производительность; проблема как правило успешно решается приобретением оотдельной рабочей станции на базе i5 с 4 ядрами + 4-8 Гб ОЗУ - разработчики счастливы, т.к. на этой машине их базы летают быстрее, чем на сервере.
Для оптимизации нагрузки, тестовые SQL-базы можно перевести в bulk recovery mode - это немного снизит нагрузку на SQL.
PS: сайт Гилева я Вам не зря рекомендовал.
PS2: PerfMon никто не отменял - начинайте с него и ищите узкое место.
