Диагностика

а что нетак то ?

Обнаружить 12309 (комментарий)

Еще раз: весь проц (да, все 4 ядра) на последнем издыхании от затяжного «подождите минуту, Ваша карточка сейчас будет доставлена из картотеки в регистратуру». Система ничего не делает (делает внешняя по отношению к ней сущность - винт), но рапортует, что обсчитывать то, что можно обсчитать - нечем. Как вылечить?

3.2 у меня на десктопе страдает абсолютно теми же самыми симптомами. Не вижу причин ставить на сервер даже для тестов.

а нормальнее описать в чем проблема то ?
я вот никаких особых проблем и невижу

Грубо: весь проц ушел в ожидание, сложные запросы, требующие вычислений и уже имеющие данные для них не обрабатываются.

и где ты вообще увидел последнее издыхание ?

ты могеш точнее обьяснить - кто такие сложные эти запросы
как ты видиш что они уже получили все данные и невыполняються
и так далее ?

вот как всегда - как тока упоминают эту проблему - никто ничего не может сказать что то точное :)

93.8%wa

ну - идет массовая запись на диск - при
Dirty: 393664 kB
это и неудивительно - больше похоже на копирование чегото бальшого в системе

вопрос то - в чем проблема ?

https://bugzilla.kernel.org/show_bug.cgi?id=12309

Сложные запросы, для которых уже все данные в наличии:

while True:
    i = 100**100

Выполняются, конечно, вот бенчмарк на одном ядре из 4:

9: 1483373 9: 1525331 9: 1564108 9: 1462624 9: 1577376 9: 1578684 9: 1577403 9: 1578514 9: 1555254 9: 1496271 9: 1419018 9: 1493458 9: 1532706

первая цифра: количество секунд, вторая - среднее количество итераций возведения в степень за это количество секунд. Места, где производительность падает - это то самое, когда wa уходит в верхнюю полку. Пока болтается на 25-50-75% наблюдаем стабильно ~1560000 итераций.

И я даже не отрицаю, что планировщик может этот IOW задвинуть в самый распоследний nice=20, но он (IOW) ведь зачем-то нужен? Значит, падает производительность VM IO, если внезапно появляется пиковая нагрузка на CPU? Опять получается: либо дискетку форматируем, либо графику рендерим?

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

падение производительности это типа
с 1525331 до 1419018 ?
152 -> 142 - это около 6% ? имхо это несколько нето падение

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

а попробуй
echo 100 > /proc/sys/vm/dirty_ratio
echo 1 > /proc/sys/vm/dirty_background_ratio

а по существу - очень похоже на то что у тебя диск не справляется с нужной частотой записи
ядро пытается это обойти - и это накапливается - увеличивая грязные страницы - и как оно превышает предел dirty_ratio - то и начинаеться драка за диск

при многопоточной работе с диском - когда все приложения рвуться ченгонить записать - колво интеруптов и переключение конетента очень бальшое

Вот с этого места поподробнее: ни в виндах, ни во всяких *BSD подобного эффекта не наблюдается. Там менее честный top/iostat/vmstat/sysstat/whatever? Или там всё же нет такой проблемы? Меня правда интересуют предыдущие два вопроса. Вообще, что значит «драка за диск»? Пишет на него ядро, приложения только скидывают страницы ядру. Причем, оно (ядро) должно же всё-таки быть спроектировано с учетом того, что скидывать сисколы на чтение/запись могут over9k приложений одновременно, так? А ядро уже полученное приоритезирует и пишет линейно. Помнится, была такая же хрень с сетевым IO. Потом изобрели netdev polling, где-то используется, где-то нет, зависит от задачи. Возможен ли аналогичный механизм в Disk IO? Если да, то почему его нет, или, если есть, какие там подводные камни, что не включен по дефолту нигде (по крайней мере из виденных мной дистрибутивов)?

с 1525331 до 1419018 ? 152 -> 142 - это около 6% ? имхо это несколько нето падение

Я же честно признался: тестилка не честная. 1 поток на одном единственном процессе. При 4 честных ядрах в башке. Вполне возможно, остальная нагрузка была раскидана планировщиком по остальным ядрам, ибо top у меня дефолтный, с обновлением данных /2sec, а между обновлениями там что угодно могло происходить.

echo 100 > /proc/sys/vm/dirty_ratio echo 1 > /proc/sys/vm/dirty_background_ratio

Попробую, конечно, как только лишние 600 гиг из базы вычищу и немного разгружу IO.

есть два параметра - dirty_rate и dirty_background_rate
когда количество грязных страниц превышает беграудное значение - то грубо говоря они начинают сливаться на диск
а когда превышает обычьное значение - то ядро останваливает все другие записи на диск и начинает сливать накопившиеся на диск

(скорее ошибаюсь - но надеюсь несильно)
по умолчанию эти параметры в процентах 20 и 10

вы попробовали их поставить в 100 и 1 ?

У меня еще DELETE FROM хреначит

всмысле все еще - или еще ? :)

Все еще...

вы попробовали их поставить в 100 и 1 ?

Вот, два часа назад врубил. Сначала dirty упал было до 32 метров, теперь вот:

MemTotal:        7999356 kB
MemFree:           37504 kB
Buffers:          462220 kB
Cached:          6729124 kB
SwapCached:          432 kB
Active:          2999192 kB
Inactive:        4344716 kB
Active(anon):     526904 kB
Inactive(anon):   172992 kB
Active(file):    2472288 kB
Inactive(file):  4171724 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       9181136 kB
SwapFree:        9140448 kB
Dirty:           1020664 kB
Writeback:          1068 kB
AnonPages:        152388 kB
Mapped:           561380 kB
Shmem:            547388 kB
Slab:             471232 kB
SReclaimable:     440300 kB
SUnreclaim:        30932 kB
KernelStack:        1984 kB
PageTables:        18340 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    13180812 kB
Committed_AS:    1248252 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      299712 kB
VmallocChunk:   34359436383 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6544 kB
DirectMap2M:     8321024 kB

и вот:

top - 11:57:58 up 92 days, 19:24,  2 users,  load average: 11.07, 10.11, 9.05
Tasks: 156 total,   2 running, 154 sleeping,   0 stopped,   0 zombie
Cpu0  : 10.0%us,  3.3%sy,  0.0%ni,  0.0%id, 86.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.3%us,  1.7%sy,  0.0%ni,  0.0%id, 97.7%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  :  1.0%us,  0.7%sy,  0.0%ni,  2.3%id, 96.1%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 10.4%id, 89.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7999356k total,  7961968k used,    37388k free,   462944k buffers
Swap:  9181136k total,    40688k used,  9140448k free,  7167300k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21121 postgres  20   0  604m 521m 517m R   10  6.7   0:37.16 postmaster
20691 postgres  20   0  601m  12m 9.8m D    5  0.2   1:32.59 postmaster
21550 postgres  20   0  602m  15m  12m D    1  0.2   0:00.14 postmaster
 4014 root      20   0  8972  476  368 S    0  0.0  14:46.83 irqbalance
 4080 zabbix    25   5 51264  856  740 S    0  0.0  70:37.12 zabbix-agentd
16326 postgres  20   0  600m 526m 523m D    0  6.7   5:33.82 postmaster
20712 postgres  20   0  856m 534m 454m S    0  6.8   0:10.76 postmaster
21263 postgres  20   0  600m  29m  27m S    0  0.4   0:00.91 postmaster
21317 postgres  20   0  604m  10m 7292 S    0  0.1   0:05.06 postmaster

Кстати, интерактивность сервера просела до «невозможно». Задержка вывода результата cat /proc/meminfo достигает 10 секунд. Заббикс уже обкричался, что SSH не работает (ага, только что перелогинился через него, адски долго, но все же)

А в iotop что? :)
А диск сам когда проверялся?
А что smart говорит?

cat /proc/interrupts

и кстати - какая файлова система ?

            CPU0       CPU1       CPU2       CPU3       
   0: 1134116895          0          0          0  IR-IO-APIC-edge      timer
   3:          1          0          0          0  IR-IO-APIC-edge    
   4:          1          0          0          0  IR-IO-APIC-edge    
   8:         31          0          0          0  IR-IO-APIC-edge      rtc0
   9:          1          0          0          0  IR-IO-APIC-fasteoi   acpi
  16:          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb3, uhci_hcd:usb6, uhci_hcd:usb7, uhci_hcd:usb8
  19:         44         92          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4, uhci_hcd:usb5
  48:          0          0          0          0  DMAR_MSI-edge      dmar0
  49:          0          0          0          0  IR-PCI-MSI-edge      aerdrv
  50:          0          0          0          0  IR-PCI-MSI-edge      aerdrv
  51:          0          0          0          0  IR-PCI-MSI-edge      aerdrv
  52:          0          0          0          0  IR-PCI-MSI-edge      aerdrv
  55:  250336385          0          0          0  IR-PCI-MSI-edge      ahci
  56:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  57:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  58:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  59:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  60:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  61:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  62:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  63:          3          0          0          0  IR-PCI-MSI-edge      ioat-msix
  64:  612842524          0          0          0  IR-PCI-MSI-edge      eth0
 NMI:          0          0          0          0   Non-maskable interrupts
 LOC:  189749458  406193287  391123470  288203683   Local timer interrupts
 SPU:          0          0          0          0   Spurious interrupts
 PMI:          0          0          0          0   Performance monitoring interrupts
 PND:          0          0          0          0   Performance pending work
 RES:     285254      97262     270090     129914   Rescheduling interrupts
 CAL:         88   44220876        152        153   Function call interrupts
 TLB:     312746      98474     138749      79755   TLB shootdowns
 TRM:          0          0          0          0   Thermal event interrupts
 THR:          0          0          0          0   Threshold APIC interrupts
 MCE:          0          0          0          0   Machine check exceptions
 MCP:      26744      26744      26744      26744   Machine check polls
 ERR:          0
 MIS:          0

ext3

Ответил даже, но пришлось удалить сообщение. А сейчас нагрузка немного упала - видимо, он прошерстил индексы по 800-гиговой таблице и начал спокойно бэкапить с -Z 9

Больше похоже на то, что у тебя тупо винч с нагрузкой не справляется. Пробегись этим делом fsck -fy по разделам.

А вапще судя по смарту все плохо.

cast KRoN73

cast KRoN73

Не, тут я не помощник. 12309 в чистом виде лет 6..7 не видел. Недавно, правда, наткнулся на затыки машины при фоновой компиляции, когда памяти из неё до 2Гб выдернул. Но не разбирался, так как перестал её как десктоп использовать (потому память и выдёргивал.)

Не, тут я не помощник. 12309 в чистом виде лет 6..7 не видел. Недавно, правда, наткнулся на затыки машины при фоновой компиляции, когда памяти из неё до 2Гб выдернул. Но не разбирался, так как перестал её как десктоп использовать (потому память и выдёргивал.)

Выхлоп смарта посмотри. фиг с ним, с 12309, скорее тут с винчем чтото.

Выхлоп в удаленных комментариях, почемуто :)

Выхлоп в удаленных комментариях, почемуто :)

Ясно. Но, вроде, всё нормально там.

3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0

Скорее всего, врёт. Значение времени раскрутки винта обычно ненулевое :)

4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 19

Хорошо.

5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 3

Не очень хорошо, но пока не смертельно. Хотя — х.з. Может случайный процесс, может винт начал осыпаться. Нужно обязательно за динамикой следить.

7 Seek_Error_Rate 0x000f 090 060 030 Pre-fail Always - 1319596116

А тут smart точно врёт. Бывает такое нередко.

Падение отзывчивости всей системы в то время, когда посгрес насилует один единственный винт (и это совсем не тот, на котором система сидит) вряд ли можно назвать штатным поведением. Да пусть он даже подыхать будет в адских муках этот винт, с какой стати я по ssh входить должен минуту?