Тормоза при записи на SSD, увеличении SWAP (и zRam)

[hardkorova]

Всем привет. Я пользуюсь HP Chromebook 14 с установленной Убунтой 14.04 и диском на 128Гб. Система под него не везде оптимизирована, но я не могу сравнить с другим ноутом с SSD, чтобы понять, в чём дело.

Собственно, во-первых при увеличении подкачки он подтормаживает на некоторое время (пока происходит процесс записи на диск). zRam просто кладёт систему - затормаживает так, что не двигается курсор. Кстати, такое же поведение с zRam есть и на слабом ноутбуке с обычным HDD.
Кроме того, во время записи на диск (например, я копировал файлы по сети) плеер (Rhythmbox, Clementine) на пару секунд зацикливает кусок музыки, делает короткую паузу а потом продолжает воспроизводить с того места, где сейчас композиция должна играть. Такое явление наблюдалось и на btrfs, и сейчас на зашифрованном ext4 под LVM (выбирал при установке).

Я попробовал выполнить команду

Код: [Выделить]

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
музыка прерывается каждую секунду, но кое-как воспроизводится, просмотр открывается долго, с подвисаниями.

Т.е. запись на диск препятствует считыванию. Что может быть виной? Шифрование? Проблемы в прошивке диска?
Для zRam тормоза - это типичный случай?

З.Ы.
В /etc/fstab прописаны noatime,nodiratime,discard.

[soarin]

1) noatime,nodiratime убираем сразу - они бестолково-вредные
с discard всё сложнее... тоже убираем его и тестируем без него.
2) модель SSD в студию

[hardkorova]

По поводу noatime,nodiratime согласен - устаревшие советы. Но от discard лучше не отказываться. Впрочем, его снятие не приносит никаких изменений.

Добавлю пару важных признаков: это 100% загрузка kworker и высокая для kswapd0 во время записи свопа. Меня посетила мысль - может, комп так подвисает из-за шифрования? Я читал, что вроде проблемы с kworker характерны для Intel Haswell, впрочем, проблема походу не такая распространённая, как казалось бы.

Ну а что касается модели, то это MyDigitalSSD MDM242-SC2 128Gb. Вот думаю, может обновление прошивки решит проблему, но больше похоже на проблемы ядра.

Впрочем, пока я не обновлю прошивку, нельзя конкретно винить ядро.

[Sly_tom_cat]

....а zRam то вам зачем? 

[soarin]

Но от discard лучше не отказываться.

Всё сложнее. Очень сильно зависит от прошивки диска https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259829
1) на устройствах с кривой прошивкой может быть писец при выставленном discard
2) на SSD от intel и samsung трим в ubuntu 14.04 включен из коробке - ибо с ними самое беспроблемное
3) при использовании криптования и trim/discard - практически гарантирован писец
PS: олсо, проверь файловую систему

[hardkorova]

....а zRam то вам зачем? 

Попытка компенсировать нехватку памяти (2 гига). Где-то писали, мол на нетбуках с Атомом работает спокойно - но не тут.

Но от discard лучше не отказываться.

Всё сложнее. Очень сильно зависит от прошивки диска https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1259829
1) на устройствах с кривой прошивкой может быть писец при выставленном discard
2) на SSD от intel и samsung трим в ubuntu 14.04 включен из коробке - ибо с ними самое беспроблемное
3) при использовании криптования и trim/discard - практически гарантирован писец
PS: олсо, проверь файловую систему

ОК. Можно аргументировать №3? Я не встречал явных жалоб на сие. Да, надо осознавать риск, делать бэкапы и проверять диск (он проверяет себя сам время от времени при запуске). Но трим поддерживается с 3.1, уже много времени прошло, материалов типа "не включайте трим и шифрование!" никто не публикует, а скорей наоборот, что лучше использовать, чем не.

[Sly_tom_cat]

hardkorova, 2 гига - это под повседневные задачи вполне себе нормально. zRam - это когда с памятью совсем совсем швах - типа 256мб...

[hardkorova]

hardkorova, 2 гига - это под повседневные задачи вполне себе нормально. zRam - это когда с памятью совсем совсем швах - типа 256мб...

Это уже относительно, на вкус и цвет. К тому же у меня своп начинает расти уже с достижения 80%, т.е. полутора гигов от 1,9. Кстати, я ещё не выяснял, почему так, ведь vm.swappiness стоит единица. 1,5 хватает только на браузер + ритмбокс, а скайп, два браузера (для отладки сайтов, скажем) и более уже начинают свопиться. Где и начинаются замечательные затыки с заеданием звука (см. сабж).
Реально комфортным числом я считаю 4 Гига, но это опять же, у каждого по-своему.

[Sly_tom_cat]

А вот единицу в swappiness записать - это не умно
Светуют менее 10 туда не писать.

[hardkorova]

А вот единицу в swappiness записать - это не умно
Светуют менее 10 туда не писать.

Читал маны, не помню такого момента. А почему?

[Sly_tom_cat]

hardkorova, а просто не понятно зачем туда писать такие мелкие значения - проще 0 написать. Но там должно быть разумное значение - а разумное - это где-то посередине.

[hardkorova]

hardkorova, а просто не понятно зачем туда писать такие мелкие значения - проще 0 написать. Но там должно быть разумное значение - а разумное - это где-то посередине.

"Разумное" - это оценочная категория, если не поддерживается какими-то референсами на мануал. У меня значение выставлено очень разумно. vm.swappiness устанавливает порог свободной ёмкости ОЗУ, после которого лишнее начинает перекидываться в своп. Т.к. у меня 1) SSD 2) при записи начинаются тормоза, выгодно сделать задействование подкачки максимально редким, когда ОЗУ уже заполнена до краёв. В остальное время я пользуюсь, как будто свопа нет, и это хорошо. И когда памяти не хватает, вместо OOM killer приходит добрый своп и сохраняет всё запущенное.

[Sly_tom_cat]

Вы только забываете что "использована" подразумевается программным кодом, а кроме "использовано" есть еще "задействовано" - задейстовано под кеши дисковых операций. И вот доводить эти кеши до 1% RAM - крайне не разумно т.к. диск без кешей - ну ОЧЧЧЧЧЕНЬ тормозит.

[hardkorova]

Вы только забываете что "использована" подразумевается программным кодом, а кроме "использовано" есть еще "задействовано" - задейстовано под кеши дисковых операций. И вот доводить эти кеши до 1% RAM - крайне не разумно т.к. диск без кешей - ну ОЧЧЧЧЧЕНЬ тормозит.

А вот это интересно, т.к. я нуб, не всё знаю. Я выше написал, что у меня свопиться начинает уже при достижении 1,5 Гиб. Системный монитор показывает, что занято 1,3 Гиб, а здесь - 1,7. Очевидно, те 0,5 Гб - это и есть разнообразные кэши, наверно и дисковый. Я могу не беспокоиться?

Код: [Выделить]

free
             total       used       free     shared    buffers     cached
Память:    1979760    1786892     192868     223332      14652     455592
-/+ буферы/кэш:    1316648     663112
Swap:      2035708     134896    1900812

На всякий случай вот ещё вывод /proc/meminfo

Код: [Выделить]

MemTotal:        1979760 kB
MemFree:          181268 kB
MemAvailable:     322836 kB
Buffers:           17704 kB
Cached:           462840 kB
SwapCached:        28048 kB
Active:           745044 kB
Inactive:         962032 kB
Active(anon):     677932 kB
Inactive(anon):   765764 kB
Active(file):      67112 kB
Inactive(file):   196268 kB
Unevictable:          16 kB
Mlocked:              16 kB
HighTotal:       1120252 kB
HighFree:          36336 kB
LowTotal:         859508 kB
LowFree:          144932 kB
SwapTotal:       2035708 kB
SwapFree:        1900816 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:       1200252 kB
Mapped:           152656 kB
Shmem:            217164 kB
Slab:              47396 kB
SReclaimable:      27880 kB
SUnreclaim:        19516 kB
KernelStack:        3912 kB
PageTables:        15288 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3025588 kB
Committed_AS:    4376704 kB
VmallocTotal:     122880 kB
VmallocUsed:       17768 kB
VmallocChunk:     102584 kB
HardwareCorrupted:     0 kB
AnonHugePages:    294912 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       43000 kB
DirectMap2M:      870400 kB


[Dt-13]

Usage with an SSD: https://wiki.gentoo.org/wiki/Zram
и https://forum.ubuntu.ru/index.php?topic=260507.msg2061640#msg2061640