Доброе время суток.
Искуство владение юниксом, это не только уменние поднять демон (что бы он просто зработал)проинсталировать ОС, но и настроить систему на максимальную производительность. Какими бы огромными ресурсами не обладал сервер, всеравно наступит такой момент, когда ему этого будет мало, так что повышать производительность сервера за счет увеличения его русрсов это последний шанс. Вот собставенно с этим и связан мой вопрос. Я 3 дня сижу над поисковиком и чтением найденых доков на эту тему. Почерпнул много полезного, но есть она проблема. В доках либо приводяться конкретные цифры (причем каким макаром они получились об этом ни слова), либо все строится на догадках. O"reilly в статье про самбу пытается давать какие-то таблицы и хочет что бы мы по ним могли оценить производительность нашей системы, беда в том что там описывается пень 133 и ультра спарк, я вот что мне делать если у меня не пень 133? Про настройку bdflush я вообще молчу, там у кого богаче фантазия тот свое и чешет (особенно возникают разнотолки с так называемыми dummny параметрами).
Что очевидно, так это то, что надо самому уметь проанализировать данные полученные от vmstat iostat sar top и ps, и тогда все станет на свои места. Вот это я и прошу помочь мне сделать (научить). Данные то получить можно но мне не с чем их сравнить что бы можно было судить что показания в норме или наоборот зашкаливают. Вот что пишет многоуважаемый O"reilly:
Disk RPM I/O Operations/second KB/second
7200 70 560
4800 60 480
3600 40 320
откуда он берт эти цифры? а где 5400?
идем дальше
CPU I/O Operations/second KB/second
Intel Pentium 133 700 5,600
Dual Pentium 133 1,200 9,600
Sun SPARC II 660 5,280
Sun SPARC 10 750 6,000
Sun Ultra 200 2,650 21,200
как можно это просчитать.
в iostat нас наверное в первую очередь интересует такие поля
avgqu-sz
The average queue length of the requests that were issued to the device.
await
The average time (in milliseconds) for I/O requests issued to the device to be served.
svctm
The average service time (in milliseconds) for I/O requests that were issued to the device.
%util
Percentage of CPU time during which I/O requests were issued to the device
с чем мне их сравнить что бы понять что твориться с системой?
оно понятно что чем меньше %util тем лучше, но существуют различные пределы, для различный режимов работы системы (при большой нагрузке понятно что %util будет большой, но может для такой нагрузке это есть нормально и больше быть не может).
теперь vmstat
r in run queue
b blocked for resources I/O, paging, and so forth
w runnable but swapped
как определить ту границу привышение которой это уже тревозный факт?
Как оказалось hdparm это не панацея от всех бед (мол винт настроил и все пашет), существуют всякие задержки тайауты и пр. которые тоже влияют на производительность. Это в первую очередь касается I/O elevator, виртуальной памяти (sysactl bdflush), количества открытых файлов, макс. количество процессов, процессов на одного юзера, настройкой TCP и т.д.
Но к этому мы прийдем только после того как найдем причину.
Надеюсь ерунду я не говорил, и такое возникало наверное у кажного в какой-то период времени. (При подготовке к сдаче экзамена по 2000 серверу обнаружению узких мест отведен ОЧЕНЬ большой раздел и большое кол-во времени.) Постарайтесь понять меня и не флеймить, мол ламер читай маны учи мат часть и т.д. Я запутался, помогите мне пожалуйста.
Вариант для распечатки
OpenNET: Виртуальная конференция (Public)
on
29-Янв-04, 14:01 (MSK)
