Фоновое удаление на разделах подкачки в Linux + SSD

11

проблема

Я хочу включить фоновые операции TRIM на разделе подкачки на диске SSD в Linux. Согласно нескольким статьям, например, этой , ядро ​​обнаруживает эту конфигурацию и автоматически выполняет операции сброса, но в моих тестах кажется, что она не работает, хотя для принудительного поведения используется опция монтирования «discard».

сценарий

  • Debian Wheezy под управлением Linux 3.2.0
  • SSD диск: 1 х 120 ГБ OCZ Vertex 3 MI
  • 2 ГБ подкачки «простой» раздел без других уровней (LVM, RAID и т. Д.)

Фон

Вот шаги, которые я следую, чтобы проверить, работает ли фоновая TRIM на разделе подкачки:

  1. Поддержка TRIM : проверьте, поддерживает ли диск SSD команды TRIM, и ядро ​​помечает устройство как невращающееся:

    # hdparm -I /dev/sda | grep TRIM
     * Data Set Management TRIM supported (limit 1 block)
     * Deterministic read data after TRIM
    
    # cat /sys/block/sda/queue/rotational
    0
    
  2. Заполнение подкачки : смонтируйте раздел, очистите все кэши виртуальных машин и настройте Linux на агрессивную перестановку, установив для vm.swappiness значение 100. Затем запустите скрипт, который выделяет всю доступную память и заставляет ядро ​​начать перестановку:

    # swapon [--discard] /dev/sda2
    # echo 3 > /proc/sys/vm/drop_caches
    # echo 100 > /proc/sys/vm/swappiness
    # ./fill-up-memory.up
    

    Сценарий запускается на сервере с 32 ГБ физической памяти + раздел подкачки 2 ГБ и создает в памяти объект размером ~ 33,8 ГБ, этого достаточно, чтобы заполнить всю память и начать обмен. Это пример скрипта, который выполняет это поведение:

    #!/usr/bin/python
    
    mem = 33.8
    testing = 'A' * int(1024 * 1024 * 1024 * mem)
    raw_input()
    
  3. Проверьте содержимое подкачки : «swapon -s» показывает, что используется 100% памяти подкачки. Используя «hdparm --read-sector», я проверяю raw-содержимое секторов раздела подкачки, и все байты установлены в «4141», что соответствует шестнадцатеричной записи для символа «A», все работает как положено. Это пример сценария для считывания посекторного содержимого раздела подкачки:

    #!/bin/bash
    
    for sector in `seq 194560 4100095` ; do
        hdparm --read-sector $sector /dev/sda
    done
    

ПРИМЕЧАНИЕ: вы можете получить начальный / конечный сектор раздела подкачки, используя parted, cfdisk и т. Д.

Когда я останавливаю сценарий, он освобождает всю память, включая распределение подкачки, «swapon -s» не возвращает использование свопа в системе. В этот момент ожидается, что Linux начинает отбрасывать содержимое раздела подкачки в фоновом режиме, но это не работает , содержимое секторов по-прежнему «4141», даже спустя несколько часов.

Я провел несколько тестов и, похоже, что Linux выполняет полную отмену только тогда, когда раздел включен с помощью swapon()системного вызова, но никогда в фоновом режиме, хотя параметры монтирования «discard» включены в / etc / fstab.

Дальнейшие исследования: blkdev_issue_discard () - это функция ядра, отвечающая за отправку команд TRIM базовым устройствам SSD, есть две уникальные ссылки на эту функцию mm/swapfile.c:

  • discard_swap() он вызывается во время процесса swapon (), если включена опция монтирования «discard», он отбрасывает весь контент, это работает как положено.
  • discard_swap_cluster() он должен отбросить содержимое подкачки кластера, но кажется, что он никогда не выполняет команду TRIM.

Вопрос: каково ожидаемое поведение Linux на устройствах swap + SSD? Он должен отбрасывать все свободные сектора / страницы или выдавать первоначальный полный сброс только тогда, когда раздел включен в процессе загрузки? Благодарю.

santisaez
источник
4
В чем смысл? Оперативная память дешева, поскольку вы достаточно хорошо себя чувствуете, имея на своем сервере 32 больших. Отключите своп, используйте SSD для чего-нибудь полезного и прекратите суетиться.
Том О'Коннор
3
Обмен не может быть отключен на этих серверах, и у них есть уникальный SSD-диск, нет возможности разместить раздел подкачки на традиционном жестком диске. Я знаю, что размещение свопа на SSD-диске - не лучший вариант, но мне было интересно, смогу ли я добиться такого же поведения «сброса» ext4 на разделах подкачки, чтобы максимально повысить производительность диска.
Сантисаез
2
Это действительно звучит как случай преждевременной оптимизации.
MikeyB
«Комментарии могут быть отредактированы только в течение 5 минут» - служит мне правым нахождением на SF, пока я на работе… как я говорил; @MikeyB На самом деле, я читал об этом. В статье в Википедии упоминалось то, о чем я не знал. «Из-за особенностей работы флэш-памяти данные не могут быть перезаписаны напрямую, как на жестком диске». Таким образом, имело бы смысл, чтобы ранее используемые блоки в swap были бы пустыми ... но будут ли они выглядеть как "0000", когда santisaez проверяет содержимое свопа?
Signal15
Это все происходит на уровне ниже операционной системы. Что касается ОС, данные в блоке находятся там до тех пор, пока они не будут перезаписаны. Дисковод отвечает за цикл чтения-стирания-записи.
MikeyB

Ответы:

1

Кажется, что discard_swap_cluster вызывается только из scan_swap_map, который, в свою очередь, вызывается из get_swap_page или get_swap_page_of_type . Так что, если я прав, отбрасывание происходит только тогда, когда будет выделена новая страница подкачки, а не когда страница освобождена.

LAV
источник
Это звучит как ошибка.
Касперд
2
Это может быть не ошибка. Таким образом, Linux может отбрасывать много страниц одновременно, вместо того, чтобы делать это по одной.
лавы
1

Возможно, ваша система имеет --discard=onceпо умолчанию. Вы пробовали монтировать с определенной опцией сброса?

# nano /etc/fstab
________________________________________________________________
...
/dev/sda2    none    swap    ..., --discard=pages,...    ...
...

и заставляя так:

# swapon --discard=pages /dev/sda2

Вы также можете попробовать создать fstrimсервис или настроить его, если он уже доступен.

kgizdov
источник
-1

Когда я останавливаю сценарий, он освобождает всю память, включая распределение подкачки, «swapon -s» не возвращает использование свопа в системе. В этот момент ожидается, что Linux начинает отбрасывать содержимое раздела подкачки в фоновом режиме, но это не работает , содержимое секторов по-прежнему «4141», даже спустя несколько часов.

Содержимое свопа фактически «отбрасывается», когда swapon -sвозвращается «своп не используется». Система не будет перезаписывать содержимое блоков (заполненных w / «4141»), потому что это SSD, а чрезмерные записи сокращают срок службы SSD. (По крайней мере, это то, что я забрал из документации)

Signal15
источник
5
Если discardиспользуется опция монтирования, команды TRIM следует отправлять на основной твердотельный накопитель, чтобы избежать проблемы усиления записи на SSD-дисках. По крайней мере, так работают другие файловые системы, например ext4.
Сантисаез
Чтобы было ясно, это действительно приведет к чтению только нулей с помощью этой команды hdparm, но только после того, как сборщик мусора на SSD
сможет