Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / IBM DB2, WebSphere, IMS, U2, etc |
![]() ![]() |
dbtwoshnick Member Откуда: Сообщений: 160 |
Может ли DB2 на одном ядре одновременно обрабатывать несколько запросов разных приложений (из LIST APPLICATION)? Если может, то как это включить? |
21 сен 16, 19:03 [19693738] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Ничего "включать" не надо. Если ядра недонагружены, а запросы выполняются долго, значит, затык где-то в другом месте. К примеру, при передаче по сети или при чтении с дисков. Типичные случаи - чтение большого количества строк по одной (что по сети, что курсор внутри курсора...), вместо того, чтобы читать и передавать большими пачками. А ещё это может быть вина клиентской части, которая не справляется. К примеру, Java читает очень большой объём данных и конвертирует Win1251 в UNICODE - и что происходит? Работает медленно, причём клиентский процессор (одно ядро) загружен на 100%, а DB2 на вид вообще не нагружена. По этому поводу люди пишут многопоточные клиентские приложения, чтобы утилизировать все клиентские ядра. Кроме того, вопрос в заголовке не соответствует вопросу в тексте. Одно (виртуальное) ядро одновременно ничего обрабатывать не может - хоть в DB2, хоть в чём-то другом. |
21 сен 16, 23:19 [19694367] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
Проблема в том, что как мне кажется, DB2 не всегда эффективно использует доступные ядра, т.е. не грузит их полностью несколькими запросами разных приложений. Может это сложно сделать, но вроде бы KVM позволяет со снижением общей производительности (измеряемой при полной загрузке) создать виртуальных ядер больше, чем физических. DB2 может грузить 4 ядра по 10% каждое. И 8 ядер тоже по 10% каждое, что в результате увеличивает общую производительность. Т.е. если бы KVM позволил на 4 физических ядрах сделать 8 виртуальных, то производительность бы повысилась несмотря на потери виртуализации, потому что DB2 нагружал бы большее количество ядер. Вообще впечатление, что DB2 намного эффективнее работает на 256 ядерном процессоре с относительно слабыми ядрами (на уровне Atom), чем на самом топовом 4 ядерном проце, потому что в последнем случае эти 4 ядра были бы загружены всего лишь на несколько процентов. |
22 сен 16, 16:57 [19697599] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
Если мое предположение из предыдущего сообщения верно и если KVM позволяет создавать vcpus больше, чем physical, то наверно можно так ускорить DB2, создав на 8 физических ядрах в 4-5 раз больше виртуальных? Что позволило бы прогружать физические ядра почти на 100%. Но тогда вопрос про тяжелые запросы, как у них с распараллеливанием по отдельным ядрам? |
22 сен 16, 17:05 [19697639] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
пишут, что магия vcpus>cpus IS POSSIBLE ессно не на ESXi ... https://serverfault.com/questions/435231/can-kvm-cpu-assignment-count-differ-from-physical-hosts-cpu-count |
22 сен 16, 17:07 [19697649] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Вы пишете, как будто у вас цель не повысить производительность, а загрузить ядра. Ну, так напишите бесконечный цикл на SQL PL и запустите в N коннектах (N >= количество ядер) - вот вам и будет загрузка всех ядер на 100%. К производительности это имеет слабое отношение. |
22 сен 16, 20:39 [19698327] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
однако производительность приложение значительно улучшилась по словам пользователей после увеличения кол-ва ядер, но они что и раньше почти простаивали, что сейчас, просто теперь их почти простаивает большее количество, чем раньше иногда только видно на отдельных ядрах проскакивает большая нагрузка как мне кажется KVM могла бы более эффективно распределить нагрузку на существующем железе при условии, если бы тяжелые запросы раскидывались по нескольким более слабым виртуальным ядрам А вообще идеальным вариантом наверно было бы пробрасывание в виртуалку ядер разной производительности от обычных физических до нескольких слабых виртуальных, представленным одним физическим. Ядрам были бы присвоены рейтинги производительности и DB2 мог бы принимать решение на какое ядро отправлять запрос в зависимости от его оценки планировщиком. |
||
23 сен 16, 04:30 [19698790] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Производительность не меряется ни загрузкой ядер, ни отзывами пользователей a la "стало получше". |
23 сен 16, 09:50 [19699120] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
Производительность конечно же меряется исключительно мониторингом, т.е. если db2top показывает, что все прекрасно, а пользователи жалуются на скорость работы, то производительность конечно же отличная, даже правильнее сказать прекрасная и превосходная! Если же многие пользователи (не один) сообщили, что значительно повысилась скорость работы после наращивания количества ядер, то это не улучшение производительности, а всего лишь впечатление впечатлительных пользователей, так сказать их галюцинации, ессно никак не связанные с производительностью DB2, это я и так знаю. При этом средняя загрузка каждого ядра проца колышется около 10%, что до, что после увеличения количества ядер. Т.е. если бы физические ядра были бы загружены на 80% теми же рассчетами, пусть хотя бы за счет распараллеливания за счет KVM (вместо DB2), то их бы потребовалось, наверно, в 8 раз меньше ... |
||
23 сен 16, 10:39 [19699281] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
Вообще где можно почитать относительно доступное объяснения, что именно DB2 может распараллеливать по ядрам CPU и в каких редакциях? Т.е. может ли DB2: 1) Раскидать один тяжелый запрос одного APPLICATION одновременно по разным ядрам одного узла (хоста)? 2) Выполнять несколько легких запросов на одном ядре псевдоодновременно, т.е. чтобы утилизацизация ядра была не 5%-10%, а в N раз больше, где N=кол-во легких запросов от разных APPLICATION, выполняющихся на этом ядре псевдоодновременно, наверно из-за ожидания IO ? |
23 сен 16, 10:49 [19699326] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Производительность не меряется мониторингом.
Может быть и галлюцинацией, запросто. Или вызвано совершенно посторонними факторами.
Вы занимаетесь поисками под фонарём. Такое впечатление, что вы даже про iostat не слышали. |
||||||||
23 сен 16, 14:44 [19700831] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Может, на Enterprise Edition при соответствующих настройках. (На самом деле я даже на Expess-C включал). Вам не рекомендую.
Это, вообще-то, норма - и не только для СУБД. Ну, может, у вас асинхронный доступ к файловой системе не включён. Это как бы не DB2 проблема. |
||||
23 сен 16, 14:50 [19700872] Ответить | Цитировать Сообщить модератору |
Victor Metelitsa Member Откуда: Тюмень Сообщений: 2551 |
Да неважно там с файловой системой. Распределением процессов/нитей по ядрам занимается операционная система. Именно она, когда процесс чего-то ждёт, отдаёт ядро другому процессу. DB2 может... ну, сказать ОС, что можно использовать только столько-то ядер, потому что лицензия не позволяет. |
23 сен 16, 15:00 [19700935] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
[quot Victor Metelitsa]
Пожалуйста, подскажите, где про это можно подробнее почитать? Что за асинхронный доступ к файловой системе? Чей доступ, где он включается? |
||
23 сен 16, 15:34 [19701245] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
в iostat смотрел утилизацию дисков, она сейчас от 50% до 80% примерно пляшет для HDD и от 5% до 10% для SSD |
||
23 сен 16, 15:57 [19701380] Ответить | Цитировать Сообщить модератору |
Mark Barinstein Member Откуда: Москва Сообщений: 4965 |
Агенты выполняются каждый в своей нити ОС. Как уже было сказано, DB2 не занимается рассылкой своих нитей на конкретные процессоры - этим занимается ОС. DB2 может только "привязать" свои нити к определенной группе процессоров из-за лицензионных ограничений, например, или в очень больших системах с NUMA архитектурой. Поэтому, когда вы говорите, что при той же нагрузке DB2 использует бОльшее кол-во процессоров, загружая их на те же 10%, то здесь DB2 не виновата в этой мистике. |
||
23 сен 16, 18:23 [19702047] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
Дополнительный внешним фактором, который теоретически мог повлиять на производительность системы в целом, было одновременное увеличение количества ядер и на вебсфере тоже (другой хост), может быть повлияло это? Или сфера так же как и DB2 с помощью операционки должна сначала малое кол-во ядер загрузить на все 100%, чтобы увеличение количества ядер дало хоть какой-то положительный эффект? |
23 сен 16, 18:43 [19702106] Ответить | Цитировать Сообщить модератору |
CawaSPb Member Откуда: Питер/Москва/Wroclaw Сообщений: 1100 |
И как после этого разговаривать? |
||
24 сен 16, 17:28 [19704318] Ответить | Цитировать Сообщить модератору |
dbtwoshnick Member Откуда: Сообщений: 160 |
ну простите, я же писал, что нуб и потом, получается, что сфера как-то по своему ядра распределяет, не как операционка того пожелает? CPU обоих серверов (сфера и db2) даже при малом количестве ядер были недонагружены, top который показывает общую нагрузку на все ядра в целом показывал обычно меньше 50% на сфере, как удвоение количества ядер в таком случае могло улучшить ситуацию? наверно, надо будет запустить какой-нибудь сборщик статистики за период времени и померять с разным количеством ядер на обоих серверах? |
||||
24 сен 16, 17:36 [19704334] Ответить | Цитировать Сообщить модератору |
Все форумы / IBM DB2, WebSphere, IMS, U2, etc | ![]() |