Ох уж эти sysv-семафоры: $ ipcs -s -i 426007 Semaphore Array semid=426007 ... semnum value ncount zcount pid 0 0 0 0 580473 $ stat /proc/580473 stat: cannot statx '/proc/580473': No such file or directory $ stat /proc/*/task/580473 stat: cannot statx '/proc/*/task/580473': No such file or directory

predictable interface names my ass, в 2024 году они всё ещё меняются с ens3 на enp0s2 после ребута

> the Linux kernel Dirty page flush algorithm does not scale to large memory sizes, so anytime the Dirty page in /proc/meminfo exceeds around 1GB the writeback speed slows down progressively and eventually the /proc/sys/vm/dirty_ratio or /proc/sys/vm/dirty_bytes limit is exceeded and the kernel starts throttling all writes to keep the Dirty pages from growing any further. > > To maintain high write speed (in OPs case up to 800Mb/sec, can easily be 2 Gb/sec for a hardware RAID controller with cache) you need to counter intuitively lower the /proc/sys/vm/dirty_bytes and dirty_background_bytes to 256M and 64M respectively > > Make sure you do a sync first otherwise the system will freeze on writes for several hours until the Dirty page value in /proc/meminfo drops below the new value in /proc/sys/vm/dirty_bytes. The sync will also take several hours, but at least the system will not be frozen during this time. https://serverfault.com/a/995658

OOM всё чаще стал приходить в момент, когда памяти, казалось бы, ещё дофига. Кажется, я начинаю догадываться, почему: MemFree: 1940452 kB MemAvailable: 3082928 kB Buffers: 30792 kB Cached: 7696368 kB Dirty: 256 kB Writeback: 0 kB С каких пор Available стал меньше Free+Buffers+Cached-Dirty-Writeback? Кто и зачем спиздил у меня эти 6,5 гигов памяти?

После `swapoff *` количество занятой памяти уменьшилось на (29,6+29,4)—44 = 15 ГБ. WTF? Для накладных расходов на поиск страниц соотношение 1:2 какое-то дохуя жирное. В SwapCached столько не было; точно не помню, но где-то меньше пяти гигов.

Дайджест тщетности компукторного бытия, серия 1.083e+17 - Ядро после смены монитора продолжает думать, что у меня по HDMI подключен монитор с другим EDID. Высокие разрешения приходится добывать дедовским способом, содой и уксу^W^W^W генерацией modeline. - Попробовал посмотреть на wayland в 2023. sway под qemu либо не запускается вообще, либо тормозит, мучая себя хвалёным на просторах инфернетов llvmpipe-ом, либо обсирается с `Atomic commit failed: Cannot allocate memory`, хотя свободны гигабайты и затребованное разрешение даже не 1080p. А ещё иногда глитчует и рисует курсор не там, где происходит клик. Wayland дохуя готов для десктопа! Но устарели, конечно, иксы, в которых ничего подобного не наблюдается, не перепутайте. - Распоследние ядра, впрочем, не отстают и живут со сломанной графикой на QXL: https://bugzilla.redhat.com/show_bug.cgi?id=1363850 — заброшен https://bugs.freedesktop.org/show_bug.cgi?id=98322 — заброшен https://bugzilla.redhat.com/show_bug.cgi?id=1957758 — якобы починен, но норот всё равно жалуется - Каждая новая вкладка с поисковой страницей гоогле жрёт 150–200 метров минимум, каждая вторая плодит iframe с youtube в недрах элементов с «display: none», а ещё они со временем пухнут, попутно делая миллион запросов то к /gen_204, то к /_/VisualFrontendUi/gen204, то вообще к play.google.com/log. Нахуя? - Распоследний firefox после выхода иногда часами тупит с RunWatchdog: Mainthread nested event loops during hang: --- CanvasManagerParent::Shutdown - Бля, а я уж было подумал, что ядро разучилось считать память, когда увидел VmRSS бо́льший, чем MemFree-MemAvailable при отсутствии свопа: https://github.com/htop-dev/htop/issues/1051

Фигасе, tux3fs ещё шевелится: https://github.com/OGAWAHirofumi/linux-tux3/commits/hirofumi-user