Discussion:
тормоза и высокий iowait
(слишком старое сообщение для ответа)
Alexey Vlasov
2007-07-23 10:52:45 UTC
Permalink
Здравствуйте уважаемые друзья.

На сервере без всякой периодичности происходит коллапс
производительности, который сопровождается высоким LA, до 500-1500, и
iowait 100%.

Так выглядит top (при большем LA он отличается только большим
wait'ом) :
top - 13:04:09 up 55 days, 5 min, 3 users, load average: 188.97,
68.74, 25.99
Tasks: 1225 total, 5 running, 1194 sleeping, 2 stopped, 24 zombie
Cpu(s): 7.0% us, 6.5% sy, 0.0% ni, 0.0% id, 85.8% wa, 0.1% hi,
0.6% si
Mem: 4032680k total, 3993164k used, 39516k free, 11608k
buffers
Swap: 7815580k total, 1669872k used, 6145708k free, 45452k
cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16993 10957 16 0 227m 112m 4152 D 5 2.9 0:05.40 httpd
17392 27090 15 0 152m 39m 3844 S 3 1.0 0:00.11 httpd
15464 30073 16 0 154m 18m 4744 S 3 0.5 0:00.16 httpd
17715 30073 15 0 153m 18m 4716 S 3 0.5 0:00.33 httpd
17185 28488 17 0 158m 44m 3828 S 3 1.1 0:00.16 httpd
17171 28488 15 0 160m 48m 4376 S 2 1.2 0:01.48 httpd
17229 27090 15 0 152m 39m 3928 S 2 1.0 0:00.13 httpd
17072 27307 15 0 158m 50m 4432 S 2 1.3 0:00.46 httpd
17078 30774 16 0 159m 51m 4460 D 2 1.3 0:00.62 httpd

При нормальном состоянии:
top - 13:56:27 up 59 days, 57 min, 3 users, load average: 1.49,
1.63, 1.80
Tasks: 651 total, 2 running, 648 sleeping, 0 stopped, 1 zombie
Cpu(s): 7.2% us, 3.3% sy, 0.0% ni, 86.2% id, 3.0% wa, 0.0% hi,
0.2% si
Mem: 4032680k total, 3639568k used, 393112k free, 196084k
buffers
Swap: 7815580k total, 870528k used, 6945052k free, 807292k
cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29537 27307 15 0 171m 34m 4560 S 8 0.9 0:02.51 httpd
30388 27307 16 0 173m 36m 4444 R 7 0.9 0:01.57 httpd
31493 27307 15 0 166m 30m 4388 S 6 0.8 0:00.92 httpd
30909 30073 15 0 124m 32m 4344 S 3 0.8 0:00.12 httpd
31481 20632 17 0 173m 36m 4432 S 3 0.9 0:00.10 httpd
31242 29013 15 0 169m 32m 4388 S 3 0.8 0:00.35 httpd

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 121.21 0.00 62.63 0.00 1470.71 0.00
735.35 23.48 0.40 6.39 0.32 2.02
sdb 1.01 45.45 18.18 22.22 848.48 557.58 424.24
278.79 34.80 0.72 17.90 8.30 33.54
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 19.19 65.66 848.48 525.25 424.24
262.63 16.19 0.00 0.00 0.00 0.00

vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----
cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 7 874192 674664 87508 393720 0 0 944 0 1707 1678 3
1 42 55
1 8 874192 669452 87616 395012 0 0 1376 0 1705 1653 3
1 41 55
0 11 874192 671176 88136 396056 0 0 900 864 1900 1858 5
2 40 54
0 8 874104 654092 88248 397032 72 0 1464 8 1802 2203 6
2 31 61
0 3 874104 614852 88296 399040 0 0 1152 2480 2360 3418 8
3 39 50
0 5 874104 617644 88528 399408 0 0 984 2896 2312 3078 7
3 42 49
1 4 874104 601456 88800 400560 0 0 972 2860 2674 4823 16
4 53 28

При копировании файла в 600M:
2 16 873592 37352 94664 920460 0 0 13380 15012 1834 2214 4
2 6 88
2 14 873592 41628 94780 915384 0 0 11432 16536 2060 2967 10
5 15 70
4 14 873592 53932 94888 923500 0 0 4844 3160 2032 2900 8
5 11 76
1 14 873592 34244 95000 951636 0 0 19072 9032 2338 3736 9
4 10 77
0 21 873612 35184 94988 895324 0 8 9852 20804 1997 3273 7
4 10 80
3 17 873640 86368 94952 896244 0 164 19840 17632 2065 2908 7
5 6 82

Через ~5 минут тормоза проходят.

На сервере работают апачи (2.2) с PHP SAPI, sendmail, vsftpd, samba,
courier (десяток юзеров) и больше ничего нет.

Конфигурация сервера:
мат. плата Intel SR1500;
2x Xeon (четырехядерные);
RAM 4G
Диски Seagate SATA2

# cat /etc/fstab
/dev/sda2 / ext3
noatime 0 1
/dev/sda5 /var reiserfs
nosuid 0 2
/dev/sda6 /home reiserfs
nosuid,nodev 0 2
/dev/sda7 /usr ext3
noatime 0 2
/dev/sda8 /opt ext3
noatime,nodev 0 2
/dev/md1 /home2 reiserfs
nosuid,noatime,nodev,usrquota,acl 0 2
tmpfs /tmp tmpfs
nosuid,noexec,size=1024m 0 0
proc /proc
proc 0 0
/dev/sda1 swap swap
pri=5 0 0


# hdparm -tT /dev/sda5

/dev/sda5:
Timing cached reads: 5194 MB in 2.00 seconds = 2598.28 MB/sec
Timing buffered disk reads: 180 MB in 3.01 seconds = 59.86 MB/sec

DMA 0 -> 4096
DMA32 4096 -> 1048576
DMA zone: 56 pages used for memmap
DMA zone: 1075 pages reserved
DMA zone: 2867 pages, LIFO batch:0
DMA32 zone: 14280 pages used for memmap
DMA32 zone: 635577 pages, LIFO batch:31
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
ide0: BM-DMA at 0x30c0-0x30c7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x30c8-0x30cf, BIOS settings: hdc:pio, hdd:pio
ata1: SATA max UDMA/133 cmd 0xFFFFC20000006100 ctl 0x0 bmdma 0x0 irq
20
ata2: SATA max UDMA/133 cmd 0xFFFFC20000006180 ctl 0x0 bmdma 0x0 irq
20
ata3: SATA max UDMA/133 cmd 0xFFFFC20000006200 ctl 0x0 bmdma 0x0 irq
20
ata4: SATA max UDMA/133 cmd 0xFFFFC20000006280 ctl 0x0 bmdma 0x0 irq
20
ata5: SATA max UDMA/133 cmd 0xFFFFC20000006300 ctl 0x0 bmdma 0x0 irq
20
ata6: SATA max UDMA/133 cmd 0xFFFFC20000006380 ctl 0x0 bmdma 0x0 irq
20
ata1.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth
31/32)
ata1.00: configured for UDMA/133
ata2.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth
31/32)
ata2.00: configured for UDMA/133
ata3.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth
31/32)
ata3.00: configured for UDMA/133

Система Gentoo x86-64, 2.6.20.

Знатоки Linux'а просветите, чем могуть быть обусловлены такие тормоза
и высокий iowait?

--
BRGDS. Alexey Vlasov.
Ilya Anfimov
2007-07-23 11:40:18 UTC
Permalink
Post by Alexey Vlasov
Здравствуйте уважаемые друзья.
На сервере без всякой периодичности происходит коллапс
производительности, который сопровождается высоким LA, до 500-1500, и
iowait 100%.
Скорее всего -- кто-то очень активно вымывает дисковый кэш,
из-за этого приложэниями чтобы выполниться приходится постоянно
свопиться. Чаще всего бывает или из-за слишком большого
количества приложэний в памяти, или из-за того, что кто-то хочет
этой памяти слишком много и постоянно её использует.

Да, для более точной диагностики хорошо бы vmstat в момент
trashingа.

По поводу лечить -- MaxClients или что там в 2.0 в качестве
этого поставить максимум в 100. Лучшэ -- в 50. Это как самое
простое. Покажэтся, что 50 труб слишком мало -- nginx фронтэндом
для статики. Как более сложное -- постараться, чтобы файлы (или
таблицы), которые могут быть большого размера и отдаются по
запросам из сети не засасывались цэликом в память.
Alexey Vlasov
2007-07-23 15:12:37 UTC
Permalink
Post by Ilya Anfimov
Скорее всего -- кто-то очень активно вымывает дисковый кэш,
из-за этого приложэниями чтобы выполниться приходится постоянно
свопиться.
Чаще всего бывает или из-за слишком большого
количества приложэний в памяти, или из-за того, что кто-то хочет
этой памяти слишком много и постоянно её использует.
А как бы это понять кто это.
Post by Ilya Anfimov
Да, для более точной диагностики хорошо бы vmstat в момент
trashingа.
Например вот:
6 62 1591168 145596 43440 105628 2160 0 3736 180 2819 3002
11 2 0 87
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
Post by Ilya Anfimov
По поводу лечить -- MaxClients или что там в 2.0 в качестве
этого поставить максимум в 100. Лучшэ -- в 50. Это как самое
простое. Покажэтся, что 50 труб слишком мало -- nginx фронтэндом
для статики.
В качестве фронта работает Апач с mpm worker, он и занимается раздачей
статики.

Вот еще вопрос, это у всех Linux'ов так, что при копировании файла с
раздела на раздел резко увеличивается LA и iowait или только у меня?
Что у вас происходит (на примерно аналогичных системах)?

P.S. Отключение NCQ не помого, если даже хуже не сделало.

--
BRGDS. Alexey Vlasov.
Ilya Anfimov
2007-07-23 18:36:10 UTC
Permalink
Post by Alexey Vlasov
Post by Ilya Anfimov
Скорее всего -- кто-то очень активно вымывает дисковый кэш,
из-за этого приложэниями чтобы выполниться приходится постоянно
свопиться.
Чаще всего бывает или из-за слишком большого
количества приложэний в памяти, или из-за того, что кто-то хочет
этой памяти слишком много и постоянно её использует.
А как бы это понять кто это.
Учитывая, что у тебя в верху топа одни httpd -- скорее всего,
это apache. Не 100%, но 98.5. Но вообще с пониманием этого у меня
-- жопа. В смысле, это приходится всегда делать из общих
соображэний -- кто тут вообще можэт работать и кто чем занимался.
Хотя, можэшь попытаться посмотреть -- у процэссов в ps вроде есть
такие вещи, как number of page faults -- можэшь попытаться
выяснить, у кого они быстрее всех крутятся. Ну и RSS, конечно, до
определённой степени указывает на лидера. Но надо понимать, что
лидер очень можэт быть не один, и trashing начался как раз из-за
того, что много кто захотел и все всех повытесняли.
Post by Alexey Vlasov
Post by Ilya Anfimov
Да, для более точной диагностики хорошо бы vmstat в момент
trashingа.
6 62 1591168 145596 43440 105628 2160 0 3736 180 2819 3002
11 2 0 87
Ни черта себе. На этой секунде ужэ trashing?
А в syslog/dmesg сообщений об ошыбках диска при этом не валится?

Впрочем, предъяви тогда iostat 2 на десяток-другой секунд. Если
там много штук запросов к диску -- то, можэт, это ещё и не Жопа.
Post by Alexey Vlasov
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
Post by Ilya Anfimov
По поводу лечить -- MaxClients или что там в 2.0 в качестве
этого поставить максимум в 100. Лучшэ -- в 50. Это как самое
простое. Покажэтся, что 50 труб слишком мало -- nginx фронтэндом
для статики.
В качестве фронта работает Апач с mpm worker, он и занимается раздачей
статики.
Э-э-э. Честно говоря, не знаю, кто такой mpm worker. Ты уверен,
что он раздаёт статику и проксирует большые запросы хотя бы
приблизительно столь жэ эффективно, как nginx?

Кроме того, в таком случае важно выяснить, который из апачей
вылезает в верх топа по RSS при затыках.

Да, так как там с ограничением апача по количеству клиентов?
Post by Alexey Vlasov
Вот еще вопрос, это у всех Linux'ов так, что при копировании файла с
раздела на раздел резко увеличивается LA и iowait или только у меня?
Что у вас происходит (на примерно аналогичных системах)?
iowait увеличивается у всех, у кого процэссор не загружэн
счётом. LA -- у всех, у кого и так активно используется диск.

В общем, iowait -- это нормально. LA -- ну более-менее
нормально. В смысле -- если LA увеличивается с трёх до семи там.

PS Да, у тебя i/o scheduler какой стоит? Дефолтный в ранних 2.6
cfq -- дерьмо. На сервер deadline по-любому лучшэ него, с
остальными по сравнению с deadline лучшэ смотреть на месте.
Post by Alexey Vlasov
P.S. Отключение NCQ не помого, если даже хуже не сделало.
Логично.
Alexey Vlasov
2007-07-26 05:46:34 UTC
Permalink
Post by Ilya Anfimov
А в syslog/dmesg сообщений об ошыбках диска при этом не валится?
Нет, пусто.
Post by Ilya Anfimov
Впрочем, предъяви тогда iostat 2 на десяток-другой секунд. Если
За последние два дня сильных тормозов не было, так что как только, так
сразу покажу.
Post by Ilya Anfimov
Э-э-э. Честно говоря, не знаю, кто такой mpm worker. Ты уверен,
что он раздаёт статику и проксирует большые запросы хотя бы
приблизительно столь жэ эффективно, как nginx?
Насчет эффективности не знаю, сам не тестировал да и подобных статей
не
видел.
Но то, что он раздает статику, это да.
Сзади стоит обычный Apache 2 prefork.
Post by Ilya Anfimov
Кроме того, в таком случае важно выяснить, который из апачей
вылезает в верх топа по RSS при затыках.
Попробовал скачать в 30 потоков 600Mb файл на скорости в два мегабайта
в
секунду на сервере это вообще никак не отразилось.
Post by Ilya Anfimov
Да, так как там с ограничением апача по количеству клиентов?
Конфиг worker'а:
ServerLimit 160
StartServers 20
MaxClients 5600
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 35
MaxRequestsPerChild 0

Prefork:
ServerLimit 2048
MaxClients 2048
MinSpareProcessors 16
MaxProcessors 64
MaxRequestsPerChild 500
Post by Ilya Anfimov
PS Да, у тебя i/o scheduler какой стоит? Дефолтный в ранних 2.6
cfq -- дерьмо. На сервер deadline по-любому лучшэ него, с
остальными по сравнению с deadline лучшэ смотреть на месте.
Сперва был anticipatory, сейчас поставил cfq, бэкапы немного легче
проходят,
а так разницы вообще не вижу.

--
BRGDS. Alexey Vlasov.
Andrey Melnikoff
2007-07-23 12:00:24 UTC
Permalink
Alexey Vlasov <***@renton.name> wrote:
AV> Здравствуйте уважаемые друзья.

AV> На сервере без всякой периодичности происходит коллапс
AV> производительности, который сопровождается высоким LA, до 500-1500, и
AV> iowait 100%.

[....]
AV> Система Gentoo x86-64, 2.6.20.

AV> Знатоки Linux'а просветите, чем могуть быть обусловлены такие тормоза
AV> и высокий iowait?
Попробуй ncq отключить.
Ilya Anfimov
2007-07-23 12:54:54 UTC
Permalink
Post by Andrey Melnikoff
AV> Здравствуйте уважаемые друзья.
AV> На сервере без всякой периодичности происходит коллапс
AV> производительности, который сопровождается высоким LA, до 500-1500, и
AV> iowait 100%.
[....]
AV> Система Gentoo x86-64, 2.6.20.
AV> Знатоки Linux'а просветите, чем могуть быть обусловлены такие тормоза
AV> и высокий iowait?
Попробуй ncq отключить.
Главное -- чтобы первый день после этого команда на включение
обратно висела перед руками. Поскольку, скорее всего, в
критической ситуацыи станет заметно хужэ.
Wladimir Mutel
2007-07-23 17:04:25 UTC
Permalink
Post by Alexey Vlasov
Здравствуйте уважаемые друзья.
На сервере без всякой периодичности происходит коллапс
производительности, который сопровождается высоким LA, до 500-1500, и
iowait 100%.
Знатоки Linux'а просветите, чем могуть быть обусловлены такие тормоза
и высокий iowait?
Сделай ps axl | sort -nk8 - увидишь, кто больше всех память любит.
Сделай ps axm - увидишь, сколько тредов в каждом процессе апача.
И вот это попробуй порегулировать. Возможно, процессов лучше сделать
поменьше, а тредов в каждом - побольше. Пришли секцию конфига своего
апача типа такой :

<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
Alex Mizrahi
2007-07-23 18:28:07 UTC
Permalink
(message (Hello 'Alexey)
(you :wrote :on '(Mon, 23 Jul 2007 10:52:45 +0000 (UTC)))
(

AV> Mem: 4032680k total, 3993164k used, 39516k free, 11608k
AV> buffers
AV> Swap: 7815580k total, 1669872k used, 6145708k free, 45452k
AV> cached

AV> Mem: 4032680k total, 3639568k used, 393112k free, 196084k
AV> buffers
AV> Swap: 7815580k total, 870528k used, 6945052k free, 807292k
AV> cached

гм, во время трэшинга в 10 раз меньше free и в 18 раз меньше cached -- не
наводит на мысли? (также можно отметить вдвое выросший своп).
если на системе куча всего работает, то 45 MB cached означает полный копец.

причём, похоже, память уходит на анонимные выделения.

AV> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
AV> 16993 10957 16 0 227m 112m 4152 D 5 2.9 0:05.40 httpd
AV> 17392 27090 15 0 152m 39m 3844 S 3 1.0 0:00.11 httpd
AV> 15464 30073 16 0 154m 18m 4744 S 3 0.5 0:00.16 httpd
AV> 17715 30073 15 0 153m 18m 4716 S 3 0.5 0:00.33 httpd
AV> 17185 28488 17 0 158m 44m 3828 S 3 1.1 0:00.16 httpd
AV> 17171 28488 15 0 160m 48m 4376 S 2 1.2 0:01.48 httpd
AV> 17229 27090 15 0 152m 39m 3928 S 2 1.0 0:00.13 httpd
AV> 17072 27307 15 0 158m 50m 4432 S 2 1.3 0:00.46 httpd
AV> 17078 30774 16 0 159m 51m 4460 D 2 1.3 0:00.62 httpd

IMHO для апачей сильно дофига памяти. так что наверное имеет смысл
пооптимизировать в этой области. оптимизировать можно по-разному, увы без
знания того, что оно у тебя там делает сложновато.. ну для начала можно
уменьшить их количество :)

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"scorn")
Alexey Vlasov
2007-07-26 05:49:07 UTC
Permalink
Post by Alex Mizrahi
причём, похоже, память уходит на анонимные выделения.
А что это такое?

--
BRGDS. Alexey Vlasov.
Alex Mizrahi
2007-07-26 09:07:34 UTC
Permalink
(message (Hello 'Alexey)
(you :wrote :to '(Alex Mizrahi) :on '(Thu, 26 Jul 2007 05:49:07 +0000
(UTC)))
(

??>> причём, похоже, память уходит на анонимные выделения.

AV> А что это такое?

всё что не memory-mapping каких-то файлов, т.е. backed by swap.

в твоём случае скорее всего PHP выделяет место для работы скриптов, но вот
оно тебе нужно чтобы одновременно работали сотня скриптов и место в памяти
для себя там выделяло, сгружая кэш обратно на диск?

практически на 8-ядерном процессоре нет смысла гонять более 8 скриптов
одновременно (ну может 16 на всякий оверхед). а с раздачей данных медленным
клиентам может справляться reverse proxy -- они есть шибко оптимизированные
под это дело, чтоб не кушало лишних ресурсов вообще.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"scorn")
Alex Korchmar
2007-07-23 19:01:51 UTC
Permalink
Alexey Vlasov <***@renton.name> wrote:

AV> На сервере без всякой периодичности происходит коллапс
AV> производительности, который сопровождается высоким LA, до 500-1500, и
netstat -tn в помощь.

AV> Так выглядит top (при большем LA он отличается только большим
AV> wait'ом) :
банально кончилась память. Какая нахрен может быть работа апача в свопе -
мне неведомо.

AV> При нормальном состоянии:
то есть даже тут ее не хватало. А дальше пришел какой-нибудь робот
туповатенький (или даже просто почтовку вдруг прогрузило спамом), и
привет, сосем хуй.

Вариант номер раз - уменьшить число апачей (тредов, коли 2.x), впрочем,
тебе это уже предложили.
Вариант номер два или раз.a (когда апач пожалуется в лог что кончились треды
а с настройкой более серьезной конструкции не справишься)
- добавить таки памяти. Чудес не бывает, свопом ее не заменишь.

AV> Система Gentoo x86-64, 2.6.20.
зачем кстати при четырех гигах понадобилась x64?
Alex
Sergey
2007-07-23 19:06:53 UTC
Permalink
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
2. Есть объективные причины, почему не надо x86_64 ?
--
С уважением, Сергей
Alex Korchmar
2007-07-23 19:40:56 UTC
Permalink
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
S> 1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
ну вот завтра и будет. Хотя при нынешней цене памяти и нынешнем времени
жизни этой самой памяти завтра, верней всего, другая платформа будет.
А сегодня, поди, все четыре планки из четырех и заняты.

S> 2. Есть объективные причины, почему не надо x86_64 ?
мильен. Начиная с просто меньшей ее отлаженности. Кто только что
демонстрировал проблемы с srcs, я, что-ли? Заканчивая, сюрприз, более
высокими требованиями к памяти. То есть собственно реальных причин
для x64 может быть только одна - необходимость пользования чем-то,
чему нужно per process больше двух гигабайт (больше можно но уже
не нужно).

Впрочем, там, кажись, гента. Чувак хотел именно поебстись. Наверное.
Alex
Ilya Anfimov
2007-07-23 19:52:31 UTC
Permalink
Post by Alex Korchmar
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
S> 1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
ну вот завтра и будет. Хотя при нынешней цене памяти и нынешнем времени
И начнутся перестановки, ага.

[skipped]
Post by Alex Korchmar
высокими требованиями к памяти. То есть собственно реальных причин
для x64 может быть только одна - необходимость пользования чем-то,
чему нужно per process больше двух гигабайт (больше можно но уже
не нужно).
Как минимум BLAS/LAPACK быстрее. sizeof(double) тот жэ,
а регистров большэ...
Post by Alex Korchmar
Впрочем, там, кажись, гента. Чувак хотел именно поебстись. Наверное.
Alex
Alex Korchmar
2007-07-23 19:56:03 UTC
Permalink
Post by Alex Korchmar
S> 1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
ну вот завтра и будет. Хотя при нынешней цене памяти и нынешнем времени
IA> И начнутся перестановки, ага.
не начнутся. А послезавтра- один хрен пора было менять.
Post by Alex Korchmar
для x64 может быть только одна - необходимость пользования чем-то,
чему нужно per process больше двух гигабайт (больше можно но уже
не нужно).
IA> Как минимум BLAS/LAPACK быстрее. sizeof(double) тот жэ,
ну и зачем это помойке типа "апаче-пэхэпэ"?
Alex
Sergey
2007-07-23 20:02:35 UTC
Permalink
Post by Alex Korchmar
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
S> 1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
ну вот завтра и будет. Хотя при нынешней цене памяти и нынешнем времени
жизни этой самой памяти завтра, верней всего, другая платформа будет.
Не так уж быстро серверные платформы меняются. Год, иногда, другой, обычно
есть.
Post by Alex Korchmar
А сегодня, поди, все четыре планки из четырех и заняты.
У Intel, к примеру, часто 8 сейчас.
Post by Alex Korchmar
S> 2. Есть объективные причины, почему не надо x86_64 ?
мильен. Начиная с просто меньшей ее отлаженности. Кто только что
демонстрировал проблемы с srcs, я, что-ли?
Ну так они решились быстро достаточно...
--
С уважением, Сергей
Alex Korchmar
2007-07-23 21:16:56 UTC
Permalink
Post by Alex Korchmar
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
S> 1. Вдруг завтра надо будет 8/16/сколько там материнка позволяет ?
ну вот завтра и будет. Хотя при нынешней цене памяти и нынешнем времени
жизни этой самой памяти завтра, верней всего, другая платформа будет.
S> Не так уж быстро серверные платформы меняются. Год, иногда, другой, обычно
они и апгрейдятся не так быстро. То есть крайне, исключительно редко.

S> У Intel, к примеру, часто 8 сейчас.
и в них норовят напихать модулей 512. Они ж дишоооовые... и их просто так
никто не покупает.
Post by Alex Korchmar
S> 2. Есть объективные причины, почему не надо x86_64 ?
мильен. Начиная с просто меньшей ее отлаженности. Кто только что
демонстрировал проблемы с srcs, я, что-ли?
S> Ну так они решились быстро достаточно...
ну так и зачем ненужные проблемы решать?
Alex
Alexey Vlasov
2007-07-26 05:57:11 UTC
Permalink
.
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
Изначально 8 было, половина поломалась.

--
BRGDS. Alexey Vlasov.
Alex Korchmar
2007-07-26 08:18:17 UTC
Permalink
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
AV> Изначально 8 было, половина поломалась.
ну вот верни на место восемь (x64 кстати и для этого не нужен) и проблемы
производительности существенно уменьшатся.

Ну и куда там у тебя 2k апачей - понятия не имею. Вероятнее всего больше
полусотни нах не нужны. Если вдруг будут нужны - оно пожалуется в логи.
Alex
Oleg Drokin
2007-07-26 16:24:27 UTC
Permalink
Hello!
Post by Alex Korchmar
зачем кстати при четырех гигах понадобилась x64?
AV>> Изначально 8 было, половина поломалась.
AK> ну вот верни на место восемь (x64 кстати и для этого не нужен) и проблемы
AK> производительности существенно уменьшатся.

Да ну, всякие чудеса с lowmem shortage и прочая на i686 нафиг не нужны,
проще с x86_64, как мне кажется (кроме десктопа, там i686 без вариантов,
понятно).
Так что я себе везде где от 2х гигов памяти, ставлю x86_64 по этой самой
причине.

Bye,
Oleg
Alex Korchmar
2007-07-26 18:18:19 UTC
Permalink
Oleg Drokin <***@linuxhacker.ru> wrote:

AK>> ну вот верни на место восемь (x64 кстати и для этого не нужен) и проблемы
AK>> производительности существенно уменьшатся.
OD> Да ну, всякие чудеса с lowmem shortage и прочая на i686 нафиг не нужны,
OD> проще с x86_64, как мне кажется (кроме десктопа, там i686 без вариантов,
ну мне вот как-то кажется что те чудеса все привычные и давно уже
более-менее безопасная тропа в обход грабель натоптана, еще со времен
2.4. А 64 все еще в стадии "разработчики играютца". Если на самом деле надо
непрерывно адресуемого больше пары гигабайт, то вопросов нет, а чтоб обычный
апач гонять - да ну его нафиг, право.
Alex
Loading...