LINUX.ORG.RU

Linux ate my RAM - 2

 , , , ,


3

3

Имею такую ситуацию:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64290       17887       17917       18909       28485       26785
Swap:         24147       21572        2575

При этом в топе всего штук 50 процессов с потреблением памяти больше 10 Мб, и они вместе съели максимум 5 Гб памяти. Всего процессов штук 500, и не похоже чтобы лишние гигабайты были размазаны по ним тонким слоем. Отдельный вопрос про своп: неужели все это память, выделенная каким-то процессам? Где-то же должно быть написано кто это все сожрал.

Где память?

Fedora 31, kernel-5.8.18, KDE



Последнее исправление: Zeta_Gundam (всего исправлений: 1)

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

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

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

Срать можно и в бинарный файл. А над логами никто особо не думает, админам же работа нужна, хотя надо бы для них какой-то аналог json-а придумать.

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

я просто живу в этой реальности, а не в воображаемом мире

В изолированном. В масочке и шапочке из фольги. xD

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

А, например, почему подох твой Linux из какого-нибудь условного Windows (и даже из UNIX-like) ты никогда не узнаешь, потому что systemd сам в себе, даже читалку логов отдельно не завезли.

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

Ну строго говоря можно в виртуалку воткнуть линукс, нахимичить с монтированием (если есть винт с проблемным линуксом), вон даже wsl2 именно для этого запилили.

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

В описании философии Юникса его создатели не использовали ни одно из этих слов.

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

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

Что может быть проще, чем текстовая кодировка и символ перевода строки? Что может быть проще, чем писать парсер, который уже 30 лет как написан?

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

Ну строго говоря можно в виртуалку воткнуть линукс

Расчехлить условный grep/awk гораздо проще (даже в WSL2), чем возиться с поднятием виртуалки, пробросом диска и прочим. Это особенно актуально когда нужно вотпрямщаз.

Это, конечно, не решает если линукс был в LUKS, как и не поможет в случае моей FreeBSD (с текстовыми логами) в GELI да ещё и на ZFS, но в общем случае текст есть текст, содомии с кодировками уже лет двадцать как нет, а даже если и есть, большинство утилит вне зависимости от ОС уже давно научились определять автоматически, по крайней мере большинство из кодировок, даже не самых популярных.

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

Этот анон набрасывает, не корми его! ☺

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

Видимо я опять табличку с сарказмом забыл. Почти все мои комментарии надо через неё читать. На аватарку что-ли её поставить )

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

Может у тебя там на фоне забытые kvm виртуалки крутятся?

Я практически уверен что все отключил, ну и видно их в top обычно.

Zeta_Gundam
() автор топика
Ответ на: комментарий от mord0d

да, ведь это тебе придётся сделать один раз (нормальному человеку не придётся вообще), а писать однострочники приходится каждый раз, если тот же самый не подходит

anonymous
()
Ответ на: комментарий от mord0d

можно и глазками пробежаться

не доверяю таким методам, всегда проверяю грепом

почему подох твой Linux из какого-нибудь условного Windows

я просто загружусь с init=/bin/bash например

anonymous
()
Ответ на: комментарий от peregrine

можно просто иметь флэшку с live линуксом

anonymous
()
Ответ на: комментарий от kirill_rrr

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

anonymous
()
Ответ на: комментарий от mord0d

настолько проще, что регулярны темы на лоре «посоны, момогите выгрепать очередно говно», ага

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

А знаете, за последние ~30 лет прогресса появились текстовые редакторы, в которых подсвечиваются номера строк. И в них тоже можно ходить по смещению. Есть одна проблема, чтобы сказать логогрепалке по какому смещению пройти нужен экстрасенс, который укажет проблему до чтения логов. Хотя о чём это я, системд-журналд как раз и создан для массовой подготовки таких экстрасенсов.

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

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

anonymous
()
Ответ на: комментарий от mord0d

Что за илитарные страдания? Или вы считаете, что диды страдали и нам положено?

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

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

Если вещи становятся проще и удобнее в использовании, это хорошо.

А если это ведёт к невозможности решить более сложную задачу — это плохо.

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

А если это ведёт к невозможности решить более сложную задачу — это плохо

Давайте поподробнее, какую именно задачу?

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

необходимость парсинга неструктурованного текста - усложнение

Это замечательная теория. На практике всё зависит от конкретных сценариев. Для логов на десктопе grep'а хвататет практически всегда.

Kroz ★★★★★
()

Эта память освободится, когда понадобится. Если тебе так хочется циферки, запусти в терминале tail /dev/zero и подожди минуту. У меня на 16Гиг он прибился оом киллером через 22 секунды и освободил 8.8Гиг памяти вместо 2.5Гиг:

% free -m
              total        used        free      shared  buff/cache   available
Mem:          15810       11748         767        1208        3295        2539
Swap:             0           0           0

% tail /dev/zero
[1]    408650 killed     tail /dev/zero
tail /dev/zero  1,01s user 21,28s system 92% cpu 24,226 total

% free -m
              total        used        free      shared  buff/cache   available
Mem:          15810        5498        8850        1123        1461        8850
Swap:             0           0           0

fehhner ★★★★★
()
Последнее исправление: fehhner (всего исправлений: 1)
Ответ на: комментарий от fehhner

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

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Я подозреваю, что у plasma и amdgpu, но ведь приборы не показывают…

Zeta_Gundam
() автор топика
Ответ на: комментарий от NDfan

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

Zeta_Gundam
() автор топика
Ответ на: комментарий от fehhner

В том и дело, что когда надо эта память не освобождается, а просто вся система начинает тупить. Трюк с oom попробую при возможности.

А почему своп пустой, у тебя свои настройки oom и swappiness?

Zeta_Gundam
() автор топика
Ответ на: комментарий от mord0d

осталось понять зачем читать линаксовые логи под другими системами

anonymous
()
Ответ на: комментарий от mord0d

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

лол, я давно догадывался, что ты дальше локалхоста ничего не видел

anonymous
()
Ответ на: комментарий от Zeta_Gundam

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

А почему своп пустой, у тебя свои настройки oom и swappiness?

Пардон, не заметил что его вообще нет.

Zeta_Gundam
() автор топика
Ответ на: комментарий от peregrine

Мда.

В чем неправ? Текстовый файл-это разновидность бинарного файла. Бинари - любые файлы, а текстовые соответствуют более строгим критерям - содержат \n и состоят из валидных UTF-8 символов, например.

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

Ты совершенно прав в этом комментарии. Вот только ты (или другой анон, которому я отвечал) не понимаете, что простота исходит от упорядоченности структуры, которая появляется благодаря ограничениям и чем их больше, тем проще работать с такой структурой, хотя это не всегда так, но это один из факторов. Так что текстовые файлы более простые, чем рандомные бинарные.

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

У меня на 16Гиг он прибился оом киллером через 22 секунды

У меня его убивает через пять. Условия те же, только ОС нормальная другая. ☺

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

у тебя в голове точно, впрочем, ничего нового

anonymous
()
Ответ на: комментарий от Zeta_Gundam

Пардон, не заметил что его вообще нет.

Ну где-то своп удобен, я не спорю. В моём случае проще, чтобы лишний процесс прибился оом киллером, а перед этим полагало минуту. Я буду знать, что опять переборщил со вкладками или другой ерундой, а дорогой и классный ssd не будет в пустую убиваться свопом, мне этого не хотелось бы.

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

У меня его убивает через пять. Условия те же, только ОС нормальная другая. ☺

Был бы рад услышать, как ты сам собрал ядро с нужными флагами, чтобы этого добиться (иначе ось априори хуже, у меня разные ядра на выбор). Единственное, что у меня бинарный систем апдейт проходит моментально (в сравнении) и я не жду компиляции всех зависимосткй. Только как быстро забьёт оперативку огромным процессом рандомными данными, не очень зависит от того, на сколько у тебя оптимизирована система под разные задачи. Если железо и оперативка у нас одинаковые.

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

как ты сам собрал ядро с нужными флагами

GENERIC ядро, я в базовую систему вообще не лезу, меня всё устраивает. Это ж не Linux, чтобы пересобирать ядро ради +1% производительности, здесь всё искаропки хорошо.

иначе ось априори хуже, у меня разные ядра на выбор

Не вижу связи. И не вижу смысла в «разных ядрах на выбор»: это похоже на «а если надо выводить только последние двадцать строк, то я пропатчу и пересоберу tail».

Единственное, что у меня бинарный систем апдейт проходит моментально (в сравнении) и я не жду компиляции всех зависимосткй.

У меня билд-ферма компиляет пакеты для всех машин, а машины ставят уже бинарные пакеты. Официальный бинарный репозиторий я отключил, потому что мне не нравится как там собирают пакеты, а при сборке пакетов с другими опциями менеджер пакетов сходит с ума при построении дерева зависимостей — при установке пакетов он игнорирует приоритет репозиториев, а при удалении учитывает, потому при обновлении он мне ставит ruby, а при autoremove его удаляет, и так по кругу.

Только как быстро забьёт оперативку огромным процессом рандомными данными, не очень зависит от того, на сколько у тебя оптимизирована система под разные задачи.

Зато показательно чтение /dev/zero и реакция ядра на заполнение памяти. В Linux OOM Killer приходит когда уже совсем поздно и может убить не того.

Если железо и оперативка у нас одинаковые.

Про железо не знаю, а оперативки по 16G. Причём у меня убило именно tail, не смотря на то что отожрать он успел намного меньше, чем браузер с аптаймом в неделю.

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

В Linux OOM Killer приходит когда уже совсем поздно и может убить не того.

Киллер приходит мгновенно, если в памяти заблокированы исполняшки и шаред либы, лимо есть запрет вытеснения минимально объема Active(file) - демо мгновенного киллера - https://youtu.be/eJ7kRaJT4Ts

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