Поиск летучих голландцев

Примечание 1.
может я зря добавил тег убунту, т.к. ядро самосборное ииии

Примечание 2. Ранее я грешил на бтрфс. Но теперь вижу, что Рафик полностью неуиноват. Скорее всего.....

У арка есть глюк. При открытии большего аррхива он выжирает всю память. Установи vm.overcommit_memory в 2 или поставь юзерспейсный OOM киллер (nohang или earlyoom). А вместо арка юзай энгрампу.

Открой его не в арке, ну.

Запусти винду (может быть LiveCD - WinPE) и распакуй 7zipом.

Но у тебя не при перемещении/копировании лаги, а просто arc всё сожрал. Решение же 12309 на десктопе, это BFQ.

сожрал что? смотрел в монитор, всё нормально там со свободным ОЗУ было

Если скачать архив гуглдиска в tgz (50 Гб) и начать его открывать

Говори адрес, без него нормальную психушку будет сложно посоветовать.

Решение же 12309 на десктопе, это BFQ

Нет и никогда не было. Решение 12309 где угодно последние 10 лет — не путать его с любыми фризами при I/O. Я ещё застал его, правда на излёте, это было в 2008, а с 2009 он уже ни разу не встречался.

Вот именно что у линукса фризы при I/O. У Windows-а, OSX и FreeBSD такого нету, а у линукса есть. А каким конкретно говнокодом в данном случае вызван баг и что из него пофиксили не важно.

Тогда меняй планировщик на BFQ и отписывайся о результатах.

Везде есть фризы по I/O. Например, при своппинге. Винда ХР вообще за всю свою долгую жизнь так и не починила свой аналог 12309, любое копирование с медленного носителя (будь то флешка, CD, или ftp не из локалки) ставило и ставит раком систему, ничего больше делать нереально, проводник открывается секунд 15.

На винфак.

Туда и приглашаю. У нас печеньки и рабочий I/O.

прямо на саннивейл будешь вызывать?

Например, при своппинге.

начни наконец смотреть на жизнь, например без своппинга.

открой для себя радость отдыха за границей, 64битную архитектуру, горные походы, кофе в стаканчиках и макдак наконец.

примерно так?

              total        used        free      shared  buff/cache   available
Mem:          15975        4099         372         218       11502       11325
Swap:          3071           3        3068

tgz ( 50 Гб ) и начать его открывать в Ark, система начинает подтормаживать

Разве так и не должно быть? Это же сжатый монофайл, структуру которого без распаковки не прочесть.

не должно, планировщик io должен выделять на чтение этого файла ровно столько пропускной способности, чтобы это не влияло на отзывчивость интерфейса кед.

другой вопрос, какого фига вообще это влияет на задержки интерфейса и почему разрабы не засунули все критичные файлы в кеш, и какие именно разрабы, какой части дистра должны засовывать в кеш и что.
ext4?
kde?
Xorg?
тут каждый свалит на другого
яхз.

Это же сжатый монофайл

ну. 6 ядер процессора. не один.
на ссд не хватает потоков?

Use pigz, Luke :)

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

А это всё разве сразу, при запуске системы и прочих Кед, не в «кеше»? Т.е., не в оперативной памяти?

Имхо, актуальнее вопрос, «какого фига это всё (а это, по нынешним временам, малый процент от объема памяти) пытаться свопнуть, чтобы освободить память для манипуляций с пятидесятигиговым архивом?».

А вот местный товарищ hakavlad сделал костыль Prelockd, который, хоть и костыль, но работает. Но костыль.

Upd. Не, не «всё» свопнуть, конечно. Кеды свопает. Ибо запускается система, запускается SDDM, вход юзера, и Кеды уже запускаются простым юзером, которого можно всяко унижать, оскорблять, выкидывать на мороз в своп.

Upd еще раз. Или свопа нет? Тогда интересно, сколько надо оперативки, чтобы своп был вообще не нужен при работе с такими файлами... Винда читает заголовки и верит расширениям. Юниксы всем файлам во внутренний мир лезут.

Я ещё застал его, правда на излёте, это было в 2008, а с 2009 он уже ни разу не встречался.

Я в 2016 году видел на Ubuntu 16.

Intel Core I5, 16 GB RAM, 1 Tb SSD.

При копировании на USB 2.0 флешку этак информации на два ГБ можно было вставать и идти пить чай, как всё тормозило.

Ну и да — дефолт, без всякой самосборки ядер и тюнинга петрушного.

смотреть на жизнь, например без своппинга.

Вопрос: куда денутся программы (код, инструкции процессора)?

Ответ: они выгрузятся в своп файлы программ и файлы библиотек (*.so).

Как жить без своппинга в этом бренном мире?

свопа нет?

свопа НЕТ!
бога тоже НЕТ!

Вопрос: куда денутся программы (код, инструкции процессора)?

в ОЗУ

noatime,nodiratime,nobarrier,commit=900, но ничего из этого в btrfs не поможет, тем более ты скачал 50Gb при памяти 32Gb, вот она и забилась, линукс не умеет адекватно в ОЗУ, а ещё 5 звёзд

Владимир

Проявляется ли проблема на фряшечке или на серверной винде?

Ты открыл, что линукс можно собрать так, что GUI подтормаживать будет?

А если серьёзно, то проблема может быть и в Ark, и в кедах, и в иксах, и в чем угодно, так что сразу все сваливать на ядро спешить не надо.

Да и в 5.10 сделали fast_commit для ext4, неплохо бы протестировать с ним.

Вчера тыкал 33 Федору: 12309 на месте. ХЗ чем вы там в своем Линуксе занимаетесь и на какой вендекапец надеетесь с таким подходом :)

noatime,nodiratime

На кой ляд 2-е, когда включено 1-е?

Владимир

Лизонька, перелогинься!

накидайте ещё полезных советов для бобры с 12309.

Стандартное сдедство - ограничение dirty_background_bytes. Применяешь ли ты его?

У меня-то при выполнении make modules_install даже ввод в терминале на несколько секунд замерзает.

ядро самосборное

Тогда имеет смысл начать накладывать https://github.com/hakavlad/le9-patch/blob/main/le9aa1-5.10.patch

Демо ты видел уже https://youtu.be/c5bAOJkX_uc

начинает подтормаживать

This proposal adds cgroup based resource protections for the active graphical session. This is done by passing a memory protection of 250MiB to active users (capped at 10% of system memory) and by enabling other cgroup controllers (CPU, IO) to ensure important session processes get the resources they need. https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

https://gitlab.freedesktop.org/benzea/uresourced

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

vm.swappiness=1

vm.vfs_cache_pressure=50

vm.dirty_writeback_centisecs=15000

Лиза

Одного ограничения по памяти хватает. От остального будет подтормаживать, но не виснуть полностью намертво.

Говно-настройки.

«открывая» с помощью tar тоже «тормозит»? Нет? Ну значит ваш Ark унылое это самое.

в ОЗУ

ОЗУ занято важными оперативными вещами (так решила ОС), куда деваться программам, потерявшим свою оперативную значимость?

Хочу заметить, что код программ грузится в память почти как из свопа. Разница в том, что это «своп» заранее записан (во время установки программы, записи на диск), а код просто подгружается с диска по мере надобности (так же выгружается по мере наодбности).

Ты про грязные байты-то ответь - ограничиваешь их или нет?

vm.swappiness=1

Что ж, не худший вариант. Хуже только vm.swappiness=0.

он погружается в грязные байты по самую макушку

Хуже только vm.swappiness=100

Владимир

Предположение: ark распаковывает во временную папку, папка висит в tmpfs, при исчерпании памяти начинается свопинг. Подтормаживания логичны. Решение: вынести эту временную папку на физический диск. Или забить. Ты часто распаковываешь 50гб в оперативку чтобы оптимизироваться под это?

Если я прав, юзерспейсный oom это будет лечение головной боли топором.

Да, переменной vm.swappiness стоит поиграться со значениями 5, 50 и 95. 0 - однозначно плохо, а выше 100 вроде как бессмысленно. Я не помню точно приоретет вытеснения каких данных эта переменная обозначает, а нагуглить дольше чем прогнать 3 теста и выбрать лучший вариант.

Арк тормозит не потому что он унылое это самое, а по какой то вполне определённой причине. Например из за попытки впихуть 50гб данных в 32гб оперативки. Если я прав, то чувак, ты сам попросил, извини…

Я бы и рад обучиться бы, но задолбала проблема, когда при копировании, при полупустой памяти (согласно всяким там топам и т.п., включая буфферы) начинало что-то быстро-быстро свапиться (около 3МБ всего) и система раком вставала. И любые параметры свапа не спасали. Началось на Дебьяне, переполз на Убунту, теперь на Манджаре, всегда эта проблема была. В прошлом году спрашивал тут у народа что делать, посоветовали своп отрубить, я тоже сначала плевался, а потом попробовал... И мне понравилось. Разница в поведении - небо и земля. Я всё равно считаю, что свап нужен, но он должен работать нормально на десктопе, а не на серверах пейсбуков.

Вы забыли упомянуть 640Тб оперативки, которой пока что всем хватит.

Если скачать архив гуглдиска в tgz (50 Гб) и начать его открывать в Ark, система начинает подтормаживать.

Ну так дело не в системе. Оно и через 100 лет будет тормозить. Структуры данных, в которых O(n) сложность для просмотра списка файлов, виновны (да, я про tar). Ну, хорошо, что не O(n^2). Выкидывай tar

Например из за попытки впихуть 50гб данных в 32гб оперативки.

И это один из признаков унылого этого самого.