Что-то с сервером, помогите найти.

У вас сложности? Наши специалисты постараются помочь вам. Если вы сами сталкивались с похожими проблемами - поделитесь опытом.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
ViktorL
Junior member
Сообщения: 15
Зарегистрирован: 15 авг 2007, 14:45
Откуда: г.Новочеркасск

Что-то с сервером, помогите найти.

Сообщение ViktorL » 17 авг 2007, 09:48

Здравствуйте всем, писал в ветку "ПО, БД ...", но похоже дело в железе
 Имеется:
  Сервер Trinity:
  MB x7DBE-X, 5000P;
  2 X CPU Xeon 5050;  
  Memory 8 X 1Gb FB-DIMM PC2-5300 ECC;
  LSI MegaRAID SCSI 320-1 (520); BBU;  - кеширование вкл., размер кластера поставлен 64.
  5 X HDD SCSI Hitachi 10K300 73 Gb
Soft (все лицензионное):
  Windows 2003 Enterprice Edition SP1, стоит на RAID 1;
   1C 8.0.18.2. (база на другом RAID 1);
   MS SQL2005 - пока речь не о нем, т.к. тестируем производительность сервера на файловом варианте 1С8.0 БП 1,6 Gb.

  Все это тормозит больше чем 8-ка 1C на старом терминальнике Pentium D 830(3.0 Ghz), 4Gb ОЗУ.
 Возможно дело в пямяти: в Everest'e скорость чтения памяти 2659 Mb/c, и почему-то пишет DDR2-333FB SDRAM, в чем дело?
  В БИОСе пробовали разные настройки, от них становилось еще хуже.
Изображение
http://img469.imageshack.us/my.php?image=evervz1.jpg

and3008
Заслуженный сетевик
Сообщения: 1109
Зарегистрирован: 03 янв 2004, 23:30
Откуда: Н.Новгород

Сообщение and3008 » 17 авг 2007, 14:54

Интересна ваша логика. Взять какой-то софт и чего-то в нем посмотреть. После этого делать глубокомысленные выводы...

Изучите программу Perfomance Monitor. Там истина.

ViktorL
Junior member
Сообщения: 15
Зарегистрирован: 15 авг 2007, 14:45
Откуда: г.Новочеркасск

Сообщение ViktorL » 17 авг 2007, 15:36

Perfmon конечно хорошо, но я не пойму - на пользовательской машине P4 3.0, 1 Gb, SATA160 разархивирование базы длится 43 сек., на новом сервере Xeon3.0X2, 8Gb, SCSI - 57 сек.
  При работе в одной и той же базе в файловом варианте, на сервере все делается на 10-15% медленнее.
  Чем поможет Permon, он же показывает абсолютные показатели?

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 17 авг 2007, 15:59

Во-первых.
Разархивирование выполняется на скольки процессорах ? :)
Во-вторых.
Последовательный доступ относительно большими блоками - наихудшая нагрузка для LSI MegaRAID 320-1 в сравнении с софтовыми RAID.
Правильная нагрузка для него - случайный доступ мелкими блоками, как, собственно, многопользовательская БД и работает.
Это я к тому, что Вы совершенно неверно мерите и оцениваете результаты измерений, не то и не тем.
Мерить надо не разархивирование, а время исполнения хотя бы пары отчетов на фоне проведения документов Вашими 2 десятками пользователей. Вот тут разница будет заметна буквально невооруженным глазом, особенно тем, кто проводит документы (время реакции сервера на действия пользователей на фоне нагрузки).

ViktorL
Junior member
Сообщения: 15
Зарегистрирован: 15 авг 2007, 14:45
Откуда: г.Новочеркасск

Сообщение ViktorL » 17 авг 2007, 16:47

a_shats писал(а):Во-первых.
Разархивирование выполняется на скольки процессорах ? :)
Во-вторых.
Последовательный доступ относительно большими блоками - наихудшая нагрузка для LSI MegaRAID 320-1 в сравнении с софтовыми RAID.
Правильная нагрузка для него - случайный доступ мелкими блоками, как, собственно, многопользовательская БД и работает.
Это я к тому, что Вы совершенно неверно мерите и оцениваете результаты измерений, не то и не тем.
Мерить надо не разархивирование, а время исполнения хотя бы пары отчетов на фоне проведения документов Вашими 2 десятками пользователей. Вот тут разница будет заметна буквально невооруженным глазом, особенно тем, кто проводит документы (время реакции сервера на действия пользователей на фоне нагрузки).
  Хорошо, может быть все так и есть - сервер для нагрузки 2-мя десятками пользователей.
Но до того, как перевести их всех на SQL, мы хотели порадоваться быстрой работе нового сервера.
Вообще речь идет о самом страшном для них документе - ЗакрытиеМесяца. Сейчас на старом терминальнике 1 такой документ проводится от 15 мин. (янв.) до 45 мин. (дек.), в это время все остальные отдыхают, и руководству это не нравится - нельзя выписать ни РКО, ни доверенность, ни отгрузочные документы.
   Это самое ЗакрытиеМесяцы бухгалтеры любят перепроводить каждый квартал, все док-ты с начала года, причем не один раз...
  Мы надеялись, что на новом сервере все будет быстрее как раз с этим документом + надежность. Но пока что закрытие мая07 на SQL2005 длится 1 ч. 5 мин. (в файловой 8-ке 25 мин.), при этом опять же второй подключенный пользователь не может ни отчеты делать (блокировка), ни документы проводить.
  Profiler-ом сделали файл с результатами проведения 1 док. ЗакрМес, он получился размером 664 Mb, далее в "SQL чего-то-там Studio" анализировали его 4 часа 40 минут, получились рекоменадции и "ожидаемое улучшение производительности 13%". Но главное после анализа выдалось предположение "91% рабочей нагрузки содержит синтаксические ошибки".
  И в Perfmone счетчик памяти что-то вроде "количество ошибок в сек" - в среднем 200, мах 5600 - может в этом дело?

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 20 авг 2007, 13:22

Вы поставили сервер с такими же процессорами - с какой стати ОДИН отчет должен выполняться быстрее?

ViktorL
Junior member
Сообщения: 15
Зарегистрирован: 15 авг 2007, 14:45
Откуда: г.Новочеркасск

Сообщение ViktorL » 20 авг 2007, 18:25

gs писал(а):Вы поставили сервер с такими же процессорами - с какой стати ОДИН отчет должен выполняться быстрее?
  Согласен, сила сервера не в этом, но неужели это самое страшное ЗакрытиеМесяца так и будет проводиться час с небольшим?
  В ветке "Серверы - ПО, Базы Данных и их использование" выложил файл журнала счетчиков, надеюсь на чью-нибудь помощь.

Ответить

Вернуться в «Серверы - Решение проблем»

Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и 3 гостя