|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 23 Jul 2007 22:36:10
To : Alexey Vlasov
Subject : Re: тормоза и высокий iowait
--------------------------------------------------------------------------------
2007-07-23, Alexey Vlasov <renton@renton.name> пишет:
> On 23 июл, 15:40, Ilya Anfimov <i...@astelecom.ru> wrote:
>
>> Скорее всего -- кто-то очень активно вымывает дисковый кэш,
>> из-за этого приложэниями чтобы выполниться приходится постоянно
>> свопиться.
>> Чаще всего бывает или из-за слишком большого
>> количества приложэний в памяти, или из-за того, что кто-то хочет
>> этой памяти слишком много и постоянно её использует.
>
> А как бы это понять кто это.
Учитывая, что у тебя в верху топа одни httpd -- скорее всего,
это apache. Hе 100%, но 98.5. Hо вообще с пониманием этого у меня
-- жопа. В смысле, это приходится всегда делать из общих
соображэний -- кто тут вообще можэт работать и кто чем занимался.
Хотя, можэшь попытаться посмотреть -- у процэссов в ps вроде есть
такие вещи, как number of page faults -- можэшь попытаться
выяснить, у кого они быстрее всех крутятся. Hу и RSS, конечно, до
определённой степени указывает на лидера. Hо надо понимать, что
лидер очень можэт быть не один, и trashing начался как раз из-за
того, что много кто захотел и все всех повытесняли.
>
>> Да, для более точной диагностики хорошо бы vmstat в момент
>> trashingа.
>
> Hапример вот:
> 6 62 1591168 145596 43440 105628 2160 0 3736 180 2819 3002
> 11 2 0 87
Hи черта себе. Hа этой секунде ужэ trashing?
А в syslog/dmesg сообщений об ошыбках диска при этом не валится?
Впрочем, предъяви тогда iostat 2 на десяток-другой секунд. Если
там много штук запросов к диску -- то, можэт, это ещё и не Жопа.
> 0 61 1589360 150468 44348 106320 2300 0 3736 1680 2968 3164
> 7 3 0 90
> 0 56 1589284 161272 44444 108172 2556 0 3848 328 2704 3475
> 5 2 0 92
> 0 53 1588764 147540 44840 110072 3764 0 5164 168 2828 3810
> 7 2 0 91
> 1 69 1579228 28800 46948 116980 2688 0 4084 1292 2257 3669
> 8 3 0 89
> 2 67 1579704 36708 47248 117684 1888 7652 3812 8380 2078 2799
> 6 2 0 92
> 0 75 1603236 26456 47316 111924 1508 23540 2288 26020 2013 3269
> 7 4 0 89
> 0 77 1621984 26340 47664 104200 1120 20416 1488 20508 3485 8414
> 5 4 0 91
> 1 73 1623620 47736 47796 103640 1448 1636 2400 2072 2071 3845
> 8 3 0 89
> 0 63 1616192 143804 47924 102780 1536 2024 2664 2968 2405 4893
> 10 4 0 87
> 0 49 1616068 124276 48428 104020 1380 0 2576 616 2370 3930
> 10 4 0 87
> 0 47 1615752 89356 49104 104892 1380 0 2680 1112 2366 3922
> 15 7 0 78
> 1 38 1614936 69276 49588 106596 1628 0 2880 280 2199 4352
> 12 4 0 83
> 2 32 1614860 58288 50052 108440 1760 0 3432 1292 1760 3732
> 10 4 1 85
> 0 46 1630584 26296 50704 107908 1448 15988 3588 17420 1855 3034
> 11 4 3 83
> ...
> 0 23 1751148 35676 61564 112460 1328 0 4988 812 2997 5588 21
> 4 2 73
> 1 32 1750024 60896 62216 119224 1688 0 8612 668 2437 3400
> 4 3 5 88
> 1 32 1750012 74636 62696 124868 1716 0 7708 884 2431 3405
> 8 3 5 84
> 0 31 1747280 223000 63100 127260 1956 0 3892 1528 2637 3736
> 6 3 2 89
> 0 27 1747280 220536 63500 128568 468 0 1296 240 1991 2711
> 7 2 3 89
>
>> По поводу лечить -- MaxClients или что там в 2.0 в качестве
>> этого поставить максимум в 100. Лучшэ -- в 50. Это как самое
>> простое. Покажэтся, что 50 труб слишком мало -- nginx фронтэндом
>> для статики.
>
> В качестве фронта работает Апач с mpm worker, он и занимается раздачей
> статики.
Э-э-э. Честно говоря, не знаю, кто такой mpm worker. Ты уверен,
что он раздаёт статику и проксирует большые запросы хотя бы
приблизительно столь жэ эффективно, как nginx?
Кроме того, в таком случае важно выяснить, который из апачей
вылезает в верх топа по RSS при затыках.
Да, так как там с ограничением апача по количеству клиентов?
>
> Вот еще вопрос, это у всех Linux'ов так, что при копировании файла с
> раздела на раздел резко увеличивается LA и iowait или только у меня?
> Что у вас происходит (на примерно аналогичных системах)?
iowait увеличивается у всех, у кого процэссор не загружэн
счётом. LA -- у всех, у кого и так активно используется диск.
В общем, iowait -- это нормально. LA -- ну более-менее
нормально. В смысле -- если LA увеличивается с трёх до семи там.
PS Да, у тебя i/o scheduler какой стоит? Дефолтный в ранних 2.6
cfq -- дерьмо. Hа сервер deadline по-любому лучшэ него, с
остальными по сравнению с deadline лучшэ смотреть на месте.
>
> P.S. Отключение NCQ не помого, если даже хуже не сделало.
Логично.
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
