With an SSD, do I need to change my swappiness to increase SSD life?
Swap and swappiness I kept my swap partition on the old HDD. Swap on the SSD would be faster, but would also shorten the SSD’s life. My system has plenty of memory, so I also reduced the swappiness value to 0 to tell Ubuntu to only swap when absolutely necessary. I did this by adding the line vm.swappiness=0 to /etc/sysctl.conf.
Is it true that setting swappiness to zero will increase the life of my SSD? I can’t find references to this elsewhere.
7 Answers 7
Reducing the swappiness to 0 means that the OS will only start using the SSD for swap when there is no more available free RAM.
Theoretically this can increase the SSD’s lifetime because the SSD will suffer less writes. It depends whether it is practically increases the SSD’s lifetime:
- Linux rarely use the swap (especially compared to windows) even with higher swappiness values too, so this setting likely won’t change the swapping behaviour on systems with plenty of RAM compared to RAM usage. If you are short on RAM then swapping can happen quite frequently with the default value of 60, in this case decreasing swappiness will likely have a significant impact on the SSD’s write cycle limit.
- The SSD’s write endurance is still pretty high for a simple consumer usage, at least for MLC based SSDs. They say that the current MLC based SSD’s can tolerate ca. 3000-5000 write cycles before they wore out. Calculating with the 3000 limit that means that a 128 GB SSD with a daily 10 GB writes will work happily for ca. 38000 days, that means ca. 100 years. If you have a bigger SSD of course that will wore out much later. So it is very unlikely that your SSD will die because of the cells wearing out. (Of course if you use your SSD in a corporate/server environment then the daily writes are much higher, but in corporate environments usually SLC based SSD’s are used.)
- This write cycle limit is so high that the SSD manufacturers (at first SAMSUNG) started to manufacture TLC based SSD’s for consumers, which can only tolerate ca. 1000 write cycles, but are cheaper. These companies say that even these SSD’s write cycle limit will last longer than the time the product is expected to be used. (It is unlikely that in 2024 we will be still using our 128 GB SSD’s) Although if you have a TLC based SSD and you write quite frequently to that drive, e.g 50GB/day, than decreasing the swappiness value will likely have a significant effect on your SSD’s life length.
- Here is a giant thread where enthusiasts tested the SSD’s endurance by constantly writing to them. Although their test method is probably not totally correct, their results are quite impressive and soothing.
So to sum up: In theory yes, decreasing the swappiness will result in longer SSD lifespan, in practice it will likely not. But if you have a TLC based SSD and you are short on RAM and you generally write frequently to the SSD then it can have a practical effect too.
I have an MLC based, 128 GB SSD and I mostly use my system for office/browsing and I have plenty of RAM compared to my RAM usage so my SSD is not under heavy write load (although my machine is on 24/7). But because I don’t need swapping at all and it is so easy to lower the swappiness I did for myself set swappiness to 0 when I installed my SSDs, because why not do it? (Actually I set swappiness to 0 on all of my machines, even on machines which only have HDDs.)
You can check how much write has your SSD suffered during it’s life with smartctl , look for the line with Total_LBAs_Written , this will show you how much 512b sectors have been written to the SSD. (Yes I know that the SSDs have physically 4K blocks, not 512b, but SMART still says: Sector Size: 512 bytes logical/physical and with 512 blocks I get results which are comparable to the tune2fs -l Lifetime writes output.) So multiple that number with 512 and you get the writes in byte, or for short:
sudo smartctl -a /dev/sda | grep Total_LBAs_Written | awk '' will print out in GiBs for /dev/sda. (Just change the device name to your SSD’s name.) My 128 GB SSD has suffered ca. 800 GB writes in a little more than one year, that means only 7 write cycles used from the 3000.
Swap на SSD
Надумал брать себе ноут с SSD. В связи с этим вопрос:
Нужен ли своп? Если да, то какой объём? SSD от него умрёт?
Обычно я выношу /boot и /home на отдельные разделы (похоже, что теперь понадобится ещё один лишний радел для EFI, так?), если будет swap, получается 5 разделов. Я не люблю extended-разделы, потому, похоже, мне придётся отказаться от таблицы разделов msdos в пользу GPT. Всё правильно делаю?
Ну и последний вопрос я уже задавал: какую файловую систему заюзать? У меня есть SSD, с ext4 (журналирование отключено), но, может быть, есть что-то лучше?
А что, вся эта графика мышевозная из EFI не на диске хранится?
CYB3R ★★★★★ ( 13.10.12 22:04:51 MSK )
Последнее исправление: CYB3R 13.10.12 22:04:56 MSK (всего исправлений: 1)
Если своп нужен, то да. Делай.
Только плодить кучу разделов на ssd смысла не вижу.
У меня есть SSD, с ext4 (журналирование отключено), но, может быть, есть что-то лучше?
пофиг, не вникай, своп меньше переписывается, чем некоторые другие директории.
буду следить за темой, слезно
Ты за цену нормального ssd можешь обложиться ddr3.
Купи лучше ноут с сотнями памяти. Своп не нужен.
Разумеется, нет. Все в матери.
Купи лучше ноут с сотнями памяти. Своп не нужен.
И эти «сотни памяти» суспендить в астрал?
Хоте бы я узнать, откуда она там возьмется при подключении нового диска.
Дай-ка ссылку на проверяющий скрипт.
как вариант — для свопа втыкать миниатюрную флешку, которая выстувает на несколько милиметров
То есть на матери просто напаяна эта самая NAND-флешка? Или всё внутри этого чипа EFI?
Только в крайних стеснённых обстоятельствах — когда памяти маловато и/или её периодически не хватает.
похоже, мне придётся отказаться от таблицы разделов msdos в пользу GPT. Всё правильно делаю?
Целесообразность разметки носителя на разделы для ноутбука непонятна.
У меня есть SSD, с ext4 (журналирование отключено), но, может быть, есть что-то лучше?
Если оперативной памяти около 8 ГБ, целесообразно использовать более современную файловую систему, которая может утилизировать (и динамически освобождать, если надо) до 90% ОЗУ, при этом давая преимущества при работе с часто используемыми файлами: фактически рабочий набор данных будет находится в памяти и работа с ним будет происходить гораздо быстрее, без лишнего обращения к носителю. Размер файлового кэша Ext4 ограничен и не даст сильного преимущества в скорости доступа к большим файлам.
Да это как обычный BIOS, ничего особенного.
все это хранится в биос, вылазь из криокамеры.
EFI загрузка штука забавная но без надобности лучше не ставить.
я лично надобность видел 1 раз — 8 процесорный сервак на который надо было воткнуть SLES через BIOS ядро паниковало а через EFI нет.
он по-моему без журналирования не работает в принципе
Раздел или файл подкачки на SSD
Всю жизнь создаю раздел подкачки. А тут ставлю свежую систему на SSD и думаю — нафига?
Ведь основной смысл отдельного раздела на HDD был в том, что он не фрагментируется. Но зачем теперь это на SSD?
Не все ФС позволяют файл подкачки.
Кажись просыпание из файла не всегда ок работает.
Да и последовательный доступ быстрее случайного даже на ssd.
Да и последовательный доступ быстрее случайного даже на ssd.
файл подкачки создается сразу на заданный размер, врятли он сильно фрагментирован будет или его можно дефрагментировать
Сваппинг это случайный доступ в любом случае. Если на разделе не слишком мало места, файл будет создан не фрагментированным.
Сомневаюсь, что он будет использовать какую-то из таких фс.
Основной смысл раздела в том, что файл — сбоку-припёку прикручен. Фактически, начинаются костыли с гибернацией и рядом ФС. Практически если гибернация не нужна и ФС не экзотическая — похрен. Я принципиально стараюсь не делать своп файлами, мне не жалко этих нескольких гигабайт и на ссд.
А тут ставлю свежую систему на SSD и думаю — нафига?
Я уже давно своп не создаю, как у меня 16+ гигов памяти стало. Жаба душит своп на 64 гига делать.
Для hibernate. Своп ж должен всю оперативку в себя уместить. У меня сейчас ее 64 гига, поэтому от сна пришлось отказаться и не выключать комп вообще.
Рекомендую использовать раздел, если нужна hibernation (чтобы она заработала на файле подкачки требуются некоторые усилия, и то — стрёмно).
Вам нужно больше почитать про гибернацию.
Смысл этого, когда ОСь и так быстро загружается с SSD по-холодному старту. Потеря пространства.
Я уже давно своп не создаю, как у меня 16+ гигов памяти стало. Жаба душит своп на 64 гига делать.
Надо сначала выяснить, для чего и сколько нужен SWAP. На практике был случай, что какой-то программе не хватило объёма оперативки?
Мои мысли прочитал. ОЗУ 8гб за глаза на домашке с бытовым барахлом. У меня 16 вообще не парюсь. Арч. С 3 гб у ребёнка престижик без раздела подкачки. Солус, всё летает, на всё хватает.
Ну да, я могу своп и не на весь объем оперативки для гибернации создавать. Но все-равно он минимум гигов 45 должен быть в моем случае. Я ж не просто так 64 гига оперативы поставил.
Смысл в том, что не надо стартовать все, что было открыто перед выключением. Я же не на рабочий стол весь день смотрю.
Я уже выяснил — мне не нужен. Только для гибернации разве что, но проще вообще комп не вырубать.
Тут в предыдущем точно таком же сраче выяснилось, что в общем то непринципиально. Потому что подсистема свопа запрашивает у ФС номера блоков, занятые файлом и дальше использует их напрямую. В этом случае там нет оверхеда по обработке метаданных фс.
Но я всё равно не люблю своп-файлы, потому что мало ли что может пойти не так. Пользуюсь ими только в очень и очень редких случаях, когда штатного размера свопа недостаточно и надо срочно расширить за счёт ещё пары дисков.
rrr@raspberrypi:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 111,8G 0 disk [SWAP] sdb 8:16 0 465,8G 0 disk /media/data3 sde 8:64 0 931,5G 0 disk /media/data2 sdf 8:80 0 931,5G 0 disk /media/data zram0 254:0 0 100M 0 disk [SWAP] zram1 254:1 0 100M 0 disk [SWAP] zram2 254:2 0 100M 0 disk [SWAP] zram3 254:3 0 100M 0 disk [SWAP] mmcblk0 179:0 0 59,6G 0 disk ├─mmcblk0p1 179:1 0 64M 0 part ├─mmcblk0p2 179:2 0 8,1G 0 part ├─mmcblk0p3 179:3 0 8,1G 0 part / └─mmcblk0p4 179:4 0 43,4G 0 part /home rrr@raspberrypi:~$ free -m total used free shared buffers cached Mem: 942 902 39 45 12 178 -/+ buffers/cache: 711 230 Swap: 114873 857 114016 rrr@raspberrypi:~$Обратите внимание на sda. Да, это ssd. Да, на шине usb2, вместе со всем остальным.
Смысл в сохранении запущенных приложений. Гибренация всегда была дольше чем холодный старт.
Гибернация для автостарта и сохранения сессии не нужна.
Да, и не на весь объём, а только на запущенные приложения и некоторые невыгружаемые буферы. Я одно время смело укладывал в гибернацию на 4Гб раздел 7,2 гб оперативки. Потому что её боычно в районе 2Г было занято, а дисковые кеши он всё равно сбрасывает.
А мне не просто сессия нужна, мне именно состояние приложений восстановить надо.
Да, кровавый энтерпрайз во все поля.
Ну так у меня и жрут 40+ гигов запущенные приложения. Несколько виртуалок с кубернетесом, пяток проектов открытых в IDEA.
Смысл в сохранении запущенных приложений.
Список автозагрузки сложно создать? Открытые файлы не страшно потерять, если что-то пойдёт не так?
Гибернация на SSD попахивает бредом.
Гибернация на SSD попахивает бредом
На самом деле быстро и удобно, как и собственно свопинг на ССД. Ну и его износ при этом не такой страшный, потому что свопинг это оптимальная задача для блока ftl. Так пишут. Мой единственный сдохший ССД сдох от BSOD в винде во время игры.
А как в список автозагрузки запихать что в браузере должны быть открыты вот эти сайты, прокручены вот туда, аутентификация пройдена (при включеной очистке куков при закрытии браузера), текст в вормы ввода вбит, а положение окон было запомнено?
Старт новой сессии это по любому новая сессия. Как ни крути, а вот прямо с того же самого места продолжить работу не получится. Ходят слухи, что для подобной задачи Plan9 создаётся, но до массового десктопа ему ещё как ложкой до мантии копать.