Коллеги, как на убунте выгнать процессы постгреса из D-state?

Никак. Дождаться окончания операций ввода-вывода

reboot))

А не идиотский совет можно?

Rm rf и затем установить ms sql

Это как раз нормальный совет. Единственная реалистичная альтэрнатива -- поставить kernel-debug и модифицыровать внутренние структуры ядра нажывую.

мне не надо модифицировать. мне надо разобраться почему так происходит.

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

Версия ядра?

проблема началась не днях. в системе не менялось ничего. аптайм 190 дней.

я бдшник. не админ. как посмотреть?

https://phoenixnap.com/kb/check-linux-kernel-version

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

то есть если я ребутну сейчас, то машина в io-wait перестанет большую часть времени висеть?

И да, часто бывает, что подобного рода проблемы уходят когда жэлезо меняют с более кривого на менее кривого (или с менее отлажэнного на более отлажэнное). Это означает, конечно, что с жэлезом были проблемы... Но с дровами -- тожэ, поскольку нормальные дрова при проблемах с жэлезом не входят в бесконечные цыклы, а выдают ошыбки и орут в логи. Так что дрова -- в любом слуячае кривые. Как это решать -- ну, бывает, что можно ребутом обойтись и не особо это замечать. Часто можно попытаться жэлезо сменить.

4.15.0-140-generic

Понятия не имею. Во многих случаях висеть бОльшую часть времени в io-wait -- нормальная ситуацыя. Правда, есть вероятность, что я не понял, что тебе не нравится.

У тебя процэссы не выходят из D-state или можэт и выходят, только ты не можэшь посмотреть -- что у них в процэссе делается? По первоначальному вопросу у меня (и не только, вон у того, кто посоветовал reboot тожэ) сложылось впечатление, что они зависли в D-state и не отвечают вообще и висят в сисколле. Это так или эти процэссы всё-таки работают, только тебе не нравится что медленно?

работают. на скорость 0кбс. вполне возможно что это иотоп показывает ноль просто. в общем есл перебить в постгресе все сессии - начинает рассасываться проблема.

А, то есть из D-state они и сами выходят. Почти все. Тогда это не обязательно баги в ядре, да. Можэт просто база забилась или SSD накрылся.

нет. если в lwlock зависает в пг всё- не выходят. приходится по одному убивать и смотреть начинается движ или нет.

Ну... Для 4.15.0 есть уже патч на 4.15.18 Я уже молчу про то, что эту версию перестали ещё в 2018 поддерживать. Вы там вообще патчитесь? Есть 4.19.207 которая в поддержке до 2024 года. А вообще переходите на пятёрку.

Для начала -- читай сислог/клог на предмет ошыбок. SMARTS опять жэ попинай -- нет ли выявленных проблем. Протэстируй диски тэстерами скорости. Если с дисками всё в порядке -- попинай базу через pgstattuple.

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

Из D-state не выходят убиванием процэсса. lwlock -- это другое, да. Но, кстати, в районе glibc 2.20 правили некоторые ошыбки с lwlocks. Но оно реально редко встречается (притом почему-то все виденные проблемы были на цэнтоси), тожэ вряд ли.

Конечно. Интересный будет опыт 😂

ай как смишно :)