Есть (прямо скажем, неновый) сервер с двумя Xeon-ами , каждый с гипертредингом (HT). SUSE SLES 9 SP3.
Он и сервер БД, и сервер приложений, и LDAP - т е процессов много и отдыхать ему некогда. При этом утилиты (top, iostat, vmstat) показывают среднее время простоя (wa, iowait) около 50%. Вопрос : чем же занимается сервер (процессор) в эти 50% времени?

Команда top с выводом статистики по каждому процессору показывает такое:

top - 16:45:42 up 30 days, 14:28, 7 users, load average: 2.88, 2.87, 2.90
Tasks: 217 total, 1 running, 216 sleeping, 0 stopped, 0 zombie
Cpu0 : 4.4% us, 1.0% sy, 0.0% ni, 91.3% id, 3.4% wa, 0.0% hi, 0.0% si
Cpu1 : 11.1% us, 1.0% sy, 0.0% ni, 85.9% id, 2.0% wa, 0.0% hi, 0.0% si
Cpu2 : 9.8% us, 4.4% sy, 0.0% ni, 8.4% id, 76.4% wa, 0.3% hi, 0.7% si
Cpu3 : 12.5% us, 2.4% sy, 0.0% ni, 67.5% id, 17.6% wa, 0.0% hi, 0.0% si
Mem: 9284508k total, 8987228k used, 297280k free, 106196k buffers
Swap: 4200988k total, 42640k used, 4158348k free, 6546732k cached

Вопрос №2: почему отдыхают Cpu0 и Cpu1, да и Cpu3 не сильно занят (хотя бывает и занят, но чтобы все 4 "процессора" заняты - такого не видел)?

На данный момент моя версия - Linux не справляется с переключениями ( или не знает, как их сделать правильно). Прав ли я?

По идее там все распараллеливается и загрузка должна быть выше. Запущено ( не считая мелочей типа LDAP) 4 одинаковых приложения, каждое из которых обновляет ( одну и ту же) БД на этом же сервере. На каждом "процессоре" в определенный момент времени думал увидеть или приложение ( будет в основном занимать CPU) или агента БД (DB2) ( будет в основном ждать IO), т е в сумме думал получить iowait+user+sys около 100 %. Реальность далека от ожиданий.

я хочу понять, почему в данном конкретном случае увеличение количества запущенных приложений не приводит к пропорциональному увеличению производительности системы (скорости обновления БД) - ведь вроде бы ресурсы используются неполностью и ограничения ни по загрузке процессоров. ни по вводу-выводу еще не должны сильно влиять.

Или, если взглянуть с другой стороны: что здесь является главным ограничителем производительности? Если я поставлю более быстрый контроллер - это поможет? Если я увеличу количество дисков в RAID - это поможет? Если я увеличу количество процессоров - это поможет?
Почти понятно, что, если сделать и то, и другое, и третье, да еще увеличить память - то производительность возрастет. Но в силу известных обстоятельств сейчас это невозможно. Поэтому хотелось бы найти "слабое звено", или bottleneck, как говорят наши забугорные друзья.

onstat-Ищите блокировки в БД.
Вполне возможно, что несколько сессий не могут праралельно обрабатывать одну и туже запись
или пересакающийся диапазон записей.

Интересная мысль. надо проверить

miksoftВ любом случае это будет не CPU.
Кстати, пока проблему вы не обозначили. Количество запущенных приложений само по себе ни о чем не говорит.

Проблема в том, что хочется, чтобы обновления базы шли быстрее, а не получается. Например, казалось бы можно улучшить производительность за счет распараллеливания обновлений. Но распараллеливание помогает несильно. Вопрос - почему? Видимо, что-то тормозит. Вопрос - что именно? На дисковую систему это не похоже, т к в iostat я вижу вполне приемлемые svctm и await, которые несильно растут при увеличении приложений. На процессор тоже не похоже. Так что же тормозит-то? Почему плохо распараллеливается? Что DB2 не умеет этого делать - не верю. Ну вот блокировки сейчас попроверяю....

miksoftИдти надо с верхнего уровня к нижнему, а не гадать почему электроны медленно бегают при выполнении "обновления базы".

Спасибо, совет очень любезный и содержательный! Гадать про электроны больше не буду. как это я сам не догадался?

2 Ёш:

1. Я, видимо, нечетко сформулировал начальный вопрос. Понятно, что в 50% времени iowait процессор ждет ввода-вывода. Вопрос в том - что процессор делает в остальные 50% времени ( ну за вычетом usr и sys), т е когда он idle ?

2. svctm - 1-5 ms, await - до 20-25, типично 5-10. %util 100.
r/s + w/s = 200-300
что странно и что я не понимаю, avgqu-sz при этом 0.

Как я читал, для нашего SAN-а HP MSA1000 время latency до 25 ms - в пределах нормы. И SAN, и FC адаптер к нему по характеристикам дают до 20000 iops, т е r/s + w/s = 200-300 далеко не предел. Аналогично и с объемом данных, передаваемых в секунду.
Опять-таки, %util = 100 означает , что контроллер все время что-то делает, но это не означает что он не может взять в параллельную обработку еще запросы на IO (или я не прав здесь???). То же самое и с iowait: даже близость к 100% ( а у нас всего 50) не означает, что нельзя запустить параллельные процессы, которые или загрузят процессор, или будут одновременно ждать ввода-вывода.

Резюме : со стороны дисковой системы я не вижу действующих ограничений при данной загрузке. И остается главный вопрос: почему при увеличении числа приложений, осуществляющих обновления БД (выполняющих в основном "SELECT" и "UPDATE" SQL statements, если это кому-то непонятно) не происходит пропорционального увеличения объема обновлений ( т е количества этих самых UPDATE-ов) ?

Проверял блокировки. Lock wait - практически ноль. Параллельно обновления идут, но не так быстро, как хотелось бы. Препятствий к параллельному обновлению не вижу. Всего записей миллионы, обновляются за минуты десятки-сотни, т е вероятность пересечния ничтожна, да и блокировок нет, как уже написал. Разработчик говорит, что приложения способны работать параллельно. Хотя что они там понаписали - тайна, покрытая мраком. Proprietary know-how.