6. Неэффективная работа со swap. Swap не освобождается при любых завершениях программ. Хотя ps говорит, что процесса уже нет, но top показывает, что swap по-прежнему занят, а освободившаяся память распределяется под буфера. И поведение системы остаётся как прежде, как будто все проги по прежнему работают (хотя количество процессов показывается меньше) и при включении новых прог система ещё сильней задействует swap. Zram не помогает. Выключение/включение swap — то же. Через несколько минут снова в swap`е сотни мегабайт, гигабайты. То есть, настройка работы со swap — неправильная, не направлена на повышение отклика системы, хотя для Десктопов — это главный критерий.
Стоит озадачиться выяснением того, как работает кэширование в современных многозадачных системах, ну или хотя бы озвучить свои критерии эффективности. buff/cache -- это не только буферы, но и кэш; если зачитанные в ОЗУ под исполнение приложения (или сервиса) страницы сразу освободить, то повторный запуск потребует повторного зачитывания с соответствующей ФС, поскольку кэш уже эффективно сменеджерили в пользу отчётно-пустой памяти. Выбросить кэш на чтение как раз недолго, это вот dirty pages -- более дорогая по времени штука. А так на линуксах нормальная картина обычной постоявшей системы, на которой в принципе что-то происходит -- это формально занятая примерно полностью память. Вот с localhost, который с месяц назад перезагружался и работает в т.ч. сборочным узлом e2kv6: e1601:~> free -m total used free shared buff/cache available Mem: 257588 3085 80445 38334 174057 214110 Swap: 28501 0 28501 То, что формально свободна треть памяти -- скорее показатель того, что working set в целом устоялся, а основные локальные операции ввода-вывода проходят вообще на tmpfs. Вот с аналогичной системы в домашнем применении (три с лишним месяца аптайма и несколько другой характер нагрузки, сильно меньше включающий tmpfs): e16c:~> free -m total used free shared buff/cache available Mem: 128797 12883 9708 2470 109823 115913 Swap: 0 0 0 Здесь картина уже более классическая. В целом предлагаю опираться на понятие working set -- того объёма кода и данных, который должен постоянно размещаться в ОЗУ для собственно работы, а не свопинга; размер ОЗУ должен быть, соответственно, не меньше этой величины. Смотреть на потребление памяти приложениями в этом разрезе может помочь утилитка smem из одноименного пакета; обратите внимание, что по top сложно учесть на глаз эффект разделения памяти разделяемыми библиотеками (та же libc замаплена, гругря, один раз, а не по штуке целиком на каждое связанное с ней приложение), даже понимая, что смотреть стоит на RSS (resident set size), а не VIRT (хотелки софтинки). Если Вы пытаетесь запихать Альт Образование непременно с KDE на машинки с 4 Гб памяти, при этом держа по десятку вкладок в браузере -- увы, тут и zram не шибко поможет с аппетитами нынешних браузеров; надо устанавливать в варианте полегче (Xfce) и смотреть, что лишнего грузится, чтоб поотключать. Если памяти и того меньше -- лучше брать дистрибутивы, современные используемому железу (и я бы поправил по этому поводу циферки на http://altlinux.org/education), или переводить такие машинки в тонкие клиенты, если есть где крутить приложения. В общем, это не баг, по крайней мере в таких формулировках. Чтобы сделать багом, надо очень многое конкретизировать -- железо (хотя бы объём ОЗУ), задачи (хотя бы в объёме текстовых снимков экрана top), что крутили самостоятельно (тот же /proc/sys/vm/swappiness можно потрогать и забыть, а крайние потом "разрабы"). PS: если очень хочется почистить кэш -- см. что-нить по словам вроде linux free memory swap cache faq, например, http://losst.pro/kak-osvobodit-pamyat-linux
Переоткройте с доводами, если потребуется.
