|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
alexeyvgСервер загружен мелкими запросами, 2К/сек (хотя в принципе это не так и много) Очевидно, каждое приложение на действие пользователя (или даже не на действие, а при например перерисовках ) в один поток высыпает кучу последовательных запросов, ну вот оно и медленно. Там элементарно бага может быть, типа заполнение из базы кучи выпадающих комбобоксов из справочников на рефреш экрана, или что то такое.Да, кстати, недавно была такая тема . ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2013, 20:09 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Все дело в том, что у меня есть учетная система, которую я не хочу в корне переписывать. Я не думаю что разработчики изначально писали всю ее через жэ. К системе добавлено множество блоков, которая ее расширяют - вот их мы оптимизировали, оптимизируем и будем оптимизировать. Но я хочу ускорить ту систему, что уже есть. Та, что стоит на сотнях тысячах предприятий в мире. Для этого я и анализирую счетчики и т.п. У меня был сервер не очень оптимальный и на нем работала учетная система. Теперь я считаю что у меня отличный сервер судя по всем известным мне счетчикам, но скорость работы системы не увеличилась даже на половину. Ясен пень что если всю систему переписать заново, выкинув из нее все то, чем мы не пользуемся и переписать на прямые sql-запросы - все будет летать, но я хочу понять как ускорить имеющуюся систему через "железо", а не через переписывание кода. И вот поэтому я ищу идеи что бы еще такое сделать чтобы ускорить имеющуюся систему. Я задумался над оперативной памятью. Мы все привыкли к тому, что оперативная память - это супербыстро. А действительно ли это так? Вот есть у меня запрос - он выполняется 200 мс и я вижу, что он выполняется без физического чтения страниц по счетчику Pages Read / sec из SQL Server:Buffer Manager. А настолько ли быстра память? Вот память, которая у меня стоит это DDR3 1333Mhz PC3-10600, т.е. скорость ее работы 10 Гигабит/сек. Не будем считать ее двухканальной, и процессор трехканальным и тот факт что процессоров два. 10 Гигабит / сек это всего 1 Гигабайт / сек. Скорость работы жесткого диска SAS 15K порядка 300 Мегабайт / сек (давайте про иопсы не будем. У нас один компьютер, один клиент, один проц, одна планка памяти и один запрос в одну единицу времени). Получается что оперативная память работает всего лишь с такой скоростью, как работали бы три диска SAS 15K в RAID0. Но ведь это медленно очень! Поправьте меня - в чем я не прав? Наверняка в чем-то не прав, но в чем не прав в корне? Т.к. получается что лучше оставить SQLю минимум памяти и купить EVA с кучей дисков, которые дадут такую производительность, что обгонят оперативку. А как работают системы с бОльшей нагрузкой? Насколько я понимаю в разы более крутой памяти в обычной продаже пока нет. Нужно увеличивать количество физических процессоров? Если подытожить - как увеличить скорость выполнения запроса если он запускается на пустом сервере и все данные, необходимые для этого запроса находятся в оперативной памяти? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2013, 16:51 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Kaktus_давайте про иопсы не будем. У нас один компьютер, один клиент, один проц, одна планка памяти и один запрос в одну единицу времениИ ровно один сектор на диске, ага. Головка всегда сама собой оказывается на нужном месте и одному запросу одного клиента никогда не надо тупо ждать, когда же она попадёт туда, где лежит ответ на запрос. И конечно весь ответ лежит в одном месте, поэтому после первого чтения никогда не надо будет ждать перемещения к другому куску данных. Давайте не будем ни о чём, кроме последовательных и параллельных иопсов, пока вы не уясните, насколько это важно для СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2013, 16:57 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Kaktus_Вот память, которая у меня стоит это DDR3 1333Mhz PC3-10600, т.е. скорость ее работы 10 Гигабит/сек. Не будем считать ее двухканальной, и процессор трехканальным и тот факт что процессоров два. 10 Гигабит / сек это всего 1 Гигабайт / сек. Скорость работы жесткого диска SAS 15K порядка 300 Мегабайт / сек (давайте про иопсы не будем. У нас один компьютер, один клиент, один проц, одна планка памяти и один запрос в одну единицу времени). Получается что оперативная память работает всего лишь с такой скоростью, как работали бы три диска SAS 15K в RAID0. Но ведь это медленно очень!Но память не одноканальная, а процессора не два, ну и на поиск нужно время. Так что не 3 диска :-) Kaktus_Т.к. получается что лучше оставить SQLю минимум памяти и купить EVA с кучей дисков, которые дадут такую производительность, что обгонят оперативку.Неправильно. Всё равно чтение идёт через память :-) Kaktus_Если подытожить - как увеличить скорость выполнения запроса если он запускается на пустом сервере и все данные, необходимые для этого запроса находятся в оперативной памяти?Увеличением частоты процессора, увеличением частоты памяти, ывеличением распаралеливания запроса, и уменьшением распаралеливания запроса (последние 2 варианта зависят от запроса, выгодным может быть и то и другое). Kaktus_И вот поэтому я ищу идеи что бы еще такое сделать чтобы ускорить имеющуюся систему.Много раз писали - для начала найти причину. Может, вам нужно просто какую то опцию сервера переключить? Kaktus_Но я хочу ускорить ту систему, что уже есть. Та, что стоит на сотнях тысячах предприятий в мире.А, я сначала по вашим словам понял, что это ваша система. А какая, если не секрет? Тогда вариант - обратиться в службу поддержки разработчиков. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2013, 17:22 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Kaktus_Получается что оперативная память работает всего лишь с такой скоростью, как работали бы три диска SAS 15K в RAID0. Но ведь это медленно очень! Поправьте меня - в чем я не прав? Наверняка в чем-то не прав, но в чем не прав в корне? Т.к. получается что лучше оставить SQLю минимум памяти и купить EVA с кучей дисков, которые дадут такую производительность, что обгонят оперативку.Вы опять путаете производительность со временем реакции (в терминах HDD это latency). Производительность массивов дисков, действительно, может быть сравнима с производительностью оперативной памяти, но по latency у них разница на многие порядки. Так и у своего сервера вы улучшили производительность, а не время реакции. Т.е. теперь он сможет обслуживать больше пользователей без видимого ухудшения. Kaktus_Если подытожить - как увеличить скорость выполнения запроса если он запускается на пустом сервере и все данные, необходимые для этого запроса находятся в оперативной памяти?Оптимизировать запрос, в т.ч. и классическими методами - индексами и т.п. Иногда, если СУБД такое умеет и если многие объемные курсоры выбираются не полностью, помогает переключение режима оптимизатора для этих запросов в FIRST_ROWS. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2013, 17:51 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
попробую внести свои 5копеек по наблюдениям в ХР с помощью ProcessExplorer обнаружил, что система может тормозить из-за Hardware Interrupts and DPCs, очень похоже по приведенным картинкам, все не загруженно, а система тормозит Hardware Interrupts and DPCs должно быть = 0 или очень близко к 0 а судя по диаграммам - система не нагружена, возникает подозрение, что какие-то ожидания , чего-то у железа, у сетевух или еще чего, что-то не согласованно, возможно необходимо оптимизировать сеть (величину пакетов и пр.), процессор больше простаивает (ожидая готовности чего-то) вместо обработки, уж загрузка процессоров к этому очень склоняет. как пример - сеть передает, но с ошибкой, и пока весь буфер передастся система будет ждать. ведь не UDP протокол. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2013, 23:29 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Kaktus_Все дело в том, что у меня есть учетная система, которую я не хочу в корне переписывать. Я не думаю что разработчики изначально писали всю ее через жэ. К системе добавлено множество блоков, которая ее расширяют - вот их мы оптимизировали, оптимизируем и будем оптимизировать. Святая наивность. Сколько лет системе? Под какую платформу и железо она написана? Оптимизировать нужно в комплексе. А не только одну часть (но не самую главную). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 16:22 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
KhodСколько лет системе? Под какую платформу и железо она написана?Ладно, если много лет, то совсем не обязательно медленно или плохо сделано, наверняка даже наоборот. Kaktus_Все дело в том, что у меня есть учетная система, которую я не хочу в корне переписывать. Я не думаю что разработчики изначально писали всю ее через жэ. К системе добавлено множество блоков, которая ее расширяют - вот их мы оптимизировали, оптимизируем и будем оптимизировать.Вот интересно - все "сотни тысяч инсталляций" этой системы так плохо работают, или только те, которые вы меняли? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2013, 19:08 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
Kaktus_, Вместо Raid 10 сделате Raid 5 Поменяйте БД на промыштенную. Например на Oracle ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2013, 18:57 |
|
Значительное увеличение количества шпинделей
|
|||
---|---|---|---|
#18+
авторВместо Raid 10 сделате Raid 5 На запись и перезапись 5-ка будет медленнее гораздо, чем 10. По чтению примерно равно или чуть хуже. авторНапример на Oracle 1С например заточена под MS SQL, хоть на Оракле, хоть на дб\2 - ведет себя медленнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2013, 11:13 |
|
|
start [/forum/topic.php?fid=30&gotonew=1&tid=1529917]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 307ms |
total: | 460ms |
0 / 0 |