LINUX.ORG.RU
ФорумAdmin

Диагностика

 


0

1
top - 10:12:22 up 89 days, 17:39,  1 user,  load average: 11.89, 9.50, 5.66
Tasks: 159 total,   2 running, 157 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3%us,  1.1%sy,  0.0%ni,  3.5%id, 93.8%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   7999356k total,  7961808k used,    37548k free,   215052k buffers
Swap:  9181136k total,   118016k used,  9063120k free,  7245256k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19973 postgres  20   0  600m 529m 527m D    5  6.8 235:49.00 postmaster
 6167 postgres  20   0  856m 783m 526m D    4 10.0 622:55.58 postmaster
 4084 zabbix    25   5 55668 1280 1036 S    1  0.0  27:56.06 zabbix-agentd
   43 root      20   0     0    0    0 S    0  0.0   0:12.60 kswapd0
    1 root      20   0 10392  632  600 S    0  0.0   0:54.46 init
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5503  @ 2.00GHz
stepping        : 5
cpu MHz         : 1596.000
cache size      : 4096 KB
...
processor       : 3
...
MemTotal:        7999356 kB
MemFree:           37592 kB
Buffers:          223180 kB
Cached:          6812400 kB
SwapCached:        44528 kB
Active:          3801212 kB
Inactive:        3548524 kB
Active(anon):     618460 kB
Inactive(anon):   237112 kB
Active(file):    3182752 kB
Inactive(file):  3311412 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       9181136 kB
SwapFree:        9063120 kB
Dirty:            393664 kB
Writeback:           192 kB
AnonPages:        313260 kB
Mapped:           555820 kB
Shmem:            541712 kB
Slab:             460672 kB
SReclaimable:     427916 kB
SUnreclaim:        32756 kB
KernelStack:        2008 kB
PageTables:        21368 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    13180812 kB
Committed_AS:    1238528 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      299784 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

Господа, может, хоть кто-нибудь таки знает, как диагностировать и понять, где этот 12309 вообще засел, и как его лечить?

Ответ на: комментарий от ae1234

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

GateKeeper ★★ ()
Ответ на: комментарий от dada

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

GateKeeper ★★ ()
Ответ на: комментарий от ae1234

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

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

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

ae1234 ★★ ()
Ответ на: комментарий от ae1234

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

ae1234 ★★ ()
Ответ на: комментарий от pekmop1024

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

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

ae1234 ★★ ()
Ответ на: комментарий от ae1234

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

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? Опять получается: либо дискетку форматируем, либо графику рендерим?

GateKeeper ★★ ()
Ответ на: комментарий от ae1234

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

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

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

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

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

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

ae1234 ★★ ()
Ответ на: комментарий от ae1234

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

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

GateKeeper ★★ ()
Ответ на: комментарий от ae1234

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

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

GateKeeper ★★ ()
Ответ на: комментарий от ae1234

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

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

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

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

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

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

ae1234 ★★ ()
Ответ на: комментарий от ae1234

вы попробовали их поставить в 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

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

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

GateKeeper ★★ ()
Ответ на: комментарий от ae1234
            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

GateKeeper ★★ ()
Ответ на: комментарий от tazhate

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

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

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

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

cast KRoN73

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

cast KRoN73

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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


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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

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 точно врёт. Бывает такое нередко.

KRoN73 ★★★★★ ()
Ответ на: комментарий от tazhate

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

GateKeeper ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.