1 (21.09.2013 16:59:40 отредактировано fragment)

Какая-то нелепая проблема. Создал на терабайтнике раздел (на весь диск) 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

2

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

3

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

4

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

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

5

ormorph пишет:

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

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

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

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

6

fragment⇓ пишет:

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

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

fragment⇓ пишет:

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

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

7

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

8

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

9

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

10 (22.09.2013 11:35:22 отредактировано ormorph)

fragment⇓ пишет:

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

Тыц

fragment⇓ пишет:

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

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

11

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

12 (22.09.2013 12:26:57 отредактировано ormorph)

fragment⇓ пишет:

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

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

13

ormorph пишет:
fragment⇓ пишет:

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

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

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

14

fragment пишет:

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

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

15

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

Йа тьомный эльф

16

fragment⇓ пишет:

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

facepalm

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

17

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

18

fragment⇓ пишет:

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

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

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

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

19

drBatty пишет:

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

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

20

fragment⇓ пишет:

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

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

fragment⇓ пишет:

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

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

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)