Недостаточно памяти для копирования

Какая-то нелепая проблема. Создал на терабайтнике раздел (на весь диск) ext4, копирую на него каталоги со всячиной (тоже с раздела ext4). Копирую каталог размером 43,5 Гб, на девятнадцатом гигабайте кончается оперативка и зависает компьютер. Последние строки в /var/log/messages:

Sep 21 18:54:18 locus kernel: [  366.777444] [10985]  1000 10985    96898      990     234     1267             0 kio_file
Sep 21 18:54:18 locus kernel: [  366.777445] [10986]  1000 10986    96898      990     234     1267             0 kio_file
Sep 21 18:54:18 locus kernel: [  366.777446] [10987]  1000 10987    96898     1087     234     1267             0 kio_file
Sep 21 18:54:18 locus kernel: [  366.777447] [10988]  1000 10988    96898      990     234     1267             0 kio_file
Sep 21 18:54:18 locus kernel: [  366.777448] [11005]  1000 11005   136072     3693     273     1203             0 ksysguard
Sep 21 18:54:18 locus kernel: [  366.777449] [11007]  1000 11007     2474      246      12        0             0 ksysguardd
Sep 21 18:54:18 locus kernel: [  366.777451] Out of memory: Kill process 10492 (amarok) score 4 or sacrifice child
Sep 21 18:54:18 locus kernel: [  366.777453] Killed process 10492 (amarok) total-vm:2218696kB, anon-rss:6488kB, file-rss:2508kB

Оперативки 8 Гб, своп 4 Гб. При копировании наблюдал за памятью через ksysguard: там сначала идёт заполнение кэша до отказа, потом сброс и возвращение потребления памяти к начальному уровню, но за 1-2 цикла до зависания потребление оперативки не возвращается к исходному, а висит на уровне 7 Гб.

Что это за фигня такая? Уже файлы не скопируешь нормально.

Gentoo x86-64, KDE 4.11.1

А копируете чем, Дельфином? Или зависает в любом случае, независимо от того, чем копируете?

Дельфином копирую.

Случаем не игрались с параметрами ядра?
Например с параметром vm.swappiness в /etc/sysctl.conf

Вроде должно было раньше чем на 7 Гб зависать :)

ormorph написал:

Случаем не игрались с параметрами ядра?
Например с параметром vm.swappiness в /etc/sysctl.conf

Вроде должно было раньше чем на 7 Гб зависать :)

Игрались, выставил его в 0, чтобы ядро не кидало страницы в своп при живой оперативке.

А что это за фантастическое взаимодействие kio_file и swappiness такое?

"fragment⇓" написал:

Игрались, выставил его в 0, чтобы ядро не кидало страницы в своп при живой оперативке.

Можно увеличить быстродействие системы и количество используемой памяти, используя в качестве свопа сжатие zram, не выставляя при этом swappiness в ноль.
Тут немного обсуждали тыц

"fragment⇓" написал:

А что это за фантастическое  взаимодействие kio_file и swappiness такое?

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

Это, конечно, всё печально.

Это уже нифига не смешно - система виснет и при копировании через mc. Что за бред-то вообще, как мне теперь перенести данные с харда на хард?

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

"fragment⇓" написал:

Есть возможность указать размер кэша вручную?

Тыц

"fragment⇓" написал:

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

Я бы не делал поспешных выводов...
Надо бы понаблюдать за процессами в момент копирования, какой процесс потребляет наибольшее количество оперативной памяти.
Например при копировании возможно влияет virtuoso и nepomuk , так как обеспечивают быстрый поиск.
Так как в данном случае я так понял используются кеды, то сделать это можно через гуй ksysguard.

В том-то и дело, что никакой процесс не потребляет при копировании больше, чем обычно.

"fragment⇓" написал:

В том-то и дело, что никакой процесс не потребляет при копировании больше, чем обычно.

Ну тогда наверное стоит посмотреть в сторону сборки другого ядра.

ormorph написал:

[quote="fragment⇓"]В том-то и дело, что никакой процесс не потребляет при копировании больше, чем обычно.

Ну тогда наверное стоит посмотреть в сторону сборки другого ядра.[/quote]

Версию поменять? Или FreeBSD накатить? :D

fragment написал:

Версию поменять? Или FreeBSD накатить? :D

Ктож его знает...
Можно еще шаманский бубен привлечь, но это уже крайний случай!
Зы: на ядро FreeBSD без бубна ни как!

Попробовать ядро с дефолтным конфигом, который предлагает genkernel. Закомментировать все шаманства, связанные с диском и памятью из /etc/sysctl.conf, /etc/sysctl.d/* а потом по одному их обратно раскомментировать и проверять.

"fragment⇓" написал:

Игрались, выставил его в 0, чтобы ядро не кидало страницы в своп при живой оперативке.

facepalm

Hint: верните на место.

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

"fragment⇓" написал:

Так и не узнаю, что это было и как это лечить.

так и лечить. Никак :(
Дело всё в том, что копирование всегда идёт через память. Как и любая запись. Т.е. файлы читаются в память, потому вы говорите "пиши", и она "пишет". Вот только это отложенная запись, никто не ждёт, пока файл запишется, а читает дальше. Вот кеш и забивается. Можно в принципе делать sync после каждого файла, но вы состаритесь пока это всё скопируется.

Задача записи нетривиальна, перед тем, как записать файлы, система их особым образом группирует, что-бы потом быстро прочитать. В маздае такого нет, потому пишется быстрее (алгоритм тупой из 80х), но из-за этого диск фрагментируется, и потом тупит уже на чтении. Нужна дефрагментация. В линуксе "дефрагментация" УЖЕ есть в алгоритме записи. Потому запись дольше, и требует память. Лучше это НЕ менять, ибо будет скорее всего только хуже.

Помогает покупка памяти (если её мало) и покупка SSD, ибо для SSD задача расфасовки файлов значительно проще(к тому же она всё равно решена на уровне контроллера).

drBatty написал:

Дело всё в том, что копирование всегда идёт через память.

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

"fragment⇓" написал:

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

нет. Это также просто как libastral.so.

"fragment⇓" написал:

Или у ядрокодеров руки из [CENSORED] местами. Даже не знаю что вероятнее.

ну разработка Linux ядра открыта. Давай ты сделаешь? Уж поверь, Линус такой патч СРАЗУ примет.