SanDisk SSD Plus: половина производительности в Linux, чем в Windows?

6

У меня в моем ноутбуке два SSD:

  • Crucial MX300 725GB - > / DEV / SDA
  • SanDisk SSD Plus 240GB - > / DEV / SDB

Их производительность читается в Linux и Windows следующим образом:

Crucial MX300 - > на обеих ОС

sudo hdparm -tT /dev/sda # Crucial
Timing cached reads:   13700 MB in  2.00 seconds = 6854.30 MB/sec
Timing buffered disk reads: 1440 MB in  3.00 seconds = 479.58 MB/sec

SanDiskPlus->быстреевWindows!

sudohdparm-tT/dev/sdb#SanDiskTimingcachedreads:7668MBin2.00seconds=3834.92MB/secTimingbuffereddiskreads:798MBin3.00seconds=265.78MB/sec#TOOLOW!!

Последовательная производительность чтения SanDisk в Linux составляет примерно половину производительности в Windows!

Мой вопрос, конечно: Почему и может ли это быть исправлено? Это связано с тем, что SanDisk SSD Plus обрабатывается как SCSI ?

Из syslog:

~$ grep SDSSD /var/log/syslog
systemd[1]: Found device SanDisk_SDSSDA240G
kernel: [    2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133
kernel: [    2.174689] scsi 1:0:0:0: Direct-Access     ATA      SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5
smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB
smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state

По сравнению с Crucial MX300, который имеет на Linux почти такую же производительность, как и в Windows:

~$ grep MX300 /var/log/syslog
systemd[1]: Found device Crucial_CT750MX300SSD1
kernel: [    1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1,  M0CR050, max UDMA/133
smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB
smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state


Любая помощь очень приветствуется!

Edit:

Разница, которую hdparm показывает в Linux, очень реальна. Я создал два идентичных каталога: по одному на каждом из двух дисков, каждый каталог содержал около 25 ГБ файлов (36395 файлов) и запускал то же самое, что и скрипт создания контрольной суммы hashdeep на обоих серверах (скрипт просто создает контрольную сумму md5 для каждого файла в тестовых каталогах и хранит все контрольные суммы в одном файле). Вот результаты:

test-sandisk# time create-file-integrity-md5sums.sh .
real    1m49.000s
user    1m24.868s
sys 0m15.808s

test-mx300# time create-file-integrity-md5sums.sh .
real    0m54.180s
user    1m4.628s
sys 0m11.640s

Те же тесты с одним файлом 7Gb:

test-sandisk# time create-file-integrity-md5sums.sh .
real    0m26.986s
user    0m19.168s
sys 0m3.232s


test-mx300# time create-file-integrity-md5sums.sh .
real    0m17.285s
user    0m16.248s
sys 0m1.368s

Изменить 2:

Разделы «оптимальны» выровнены, и единственная разница в / sys / block / $ disk / queue - discard_zeroes_data (1 на Crucial, 0 на SanDisk). Используемые параметры файловой системы и монтирования: введите ext4 (rw, nosuid, nodev, relatime, data = ordered, uhelper = udisks2)

dmesg | grep -i sata | grep 'link up'
[    1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    
задан JLTD 15.08.2016 в 00:02
источник

3 ответа

2

Это может быть не достаточно хороший ответ, но я новичок и не могу «прокомментировать», и хотел бы поделиться с вами в случае, если это поможет:

Раньше я работал с флеш-памятью eMMC, аналогичной аппаратной основой как SSD. discard_zeroes_data звучит так, как будто это может иметь значение. Были очень медленные функции, называемые Erase и особенно Trim (например, Erase, но на основе блока чтения 4kB вместо гораздо большего блока Erase Group, необходимого для производительности. Позже была введена функция «Discard», которая не удаляла данные в все нули (действительно все-под капотом, но инвертированные для вашего удобства), но просто изменили состояние данных на «не волнует».

Итак, если вы сбросили данные на 4 КБ данных, это было быстрее, потому что не удалило, но пусть прошивка знает, что вам больше не нужны данные, и она отслеживала эту физическую область в Таблица. Это позволило механизму сбора мусора восстановить это местоположение данных (вероятно, повторно отобразить его на другом адресе) позже, когда достаточное количество его соседей можно будет удалить, скопировав необходимые данные в другую область по мере необходимости, а затем выполнив дорогостоящее «удаление» "в фоновом режиме.

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

Поэтому я не могу сказать, что именно означает «discard_zeros_data», но если бы я был вами, я бы определенно попытался изменить его на противоположное состояние и посмотреть, что произойдет. Если он читается как «объект объекта-субъекта», тогда это может быть функция безопасности, когда требуется принудительное удаление даже небольших битов данных (дорого), так что нет никаких шансов, что кто-то сможет вернуть ваши старые файлы после того, вы удалили их. Я думаю, что установка этого параметра на «Zero» на самом деле повысит производительность, если вы это прочитали, но вы видите обратное.

Также попробуйте сделать самую большую принудительную «стирание», которую вы можете использовать, используя специальные инструменты SSD или полный формат или что-то еще, и посмотрите, лучше ли производительность после этого удаления. Это, по крайней мере, даст вам некоторую информацию о проблеме.

Тип файловой системы также должен иметь значение, но я думаю, что это константа в ваших двух экспериментах.

    
ответ дан Starman 24.05.2017 в 19:01
2

Сравнение с USB-накопителями

Простые USB-накопители постепенно замедляются после использования некоторое время. Такие диски не имеют функции отбрасывания (насколько я знаю, я не говорю о продвинутых и очень дорогих играх). Вытирая все диски, перезапись нулями (или внутренними) снова вернет скорость. По собственному опыту я знаю, что это относится к Sandeng Extreme pendrives, которые бывают быстрыми, когда новые (по сравнению с другими простыми USB-накопителями).

Итак, я могу ожидать, что метод отбрасывания (или его отсутствие) может нести ответственность за падение производительности и в вашем SSD Sandisk. Я думаю, что ответ @ Starman добавляет ценную информацию для решения вашей проблемы.

Вы можете

  • попробуйте оставить систему бездействующей в течение ночи и проверить, использовало ли она время простоя, чтобы отбросить то, что следует отбросить. Если вам не повезло, вы можете

  • стереть свободное пространство диска и проверить, улучшает ли производительность,

  • попробуйте найти опцию mount в linux или некоторые настройки SSD, которые улучшат производительность.

Инструменты

  • zerofree - эффективный инструмент для файловых систем ext . См. Эту ссылку,

    manpages.ubuntu.com/manpages/zesty/man8/zerofree.8.html

  • В противном случае (если вы проверите и дважды отметьте, что все правильно), вы можете использовать dd для создания огромного файла blank , содержащего нули, и затем стереть его (медленно, но работает во всех файловых системах).

    Загрузитесь с другого диска, например, с живого USB-накопителя

    cd <mountpoint-of-the-target-partition>  # for example: cd /mnt
    sudo dd if=/dev/zero of=blank bs=4096
    

    Пусть он запустится до тех пор, пока он не остановится, потому что диск заполнен и после этого удалите файл blank . Это предполагает, что нет полезного файла с именем blank .

    sudo rm blank
    

    Предупреждение: dd - мощный, но опасный инструмент, поэтому проверьте и дважды проверьте, что вы не уничтожите ценные данные. В этом случае играть безопасно - сохранить все ценные на подключенных дисках в другое место (например, на внешний диск, который отключен впоследствии).

Протрите все устройство

Мой метод для USB-накопителей - стереть все устройство (не только свободное пространство между файлами в частично заполненном разделе). Я думаю, что это самый эффективный метод для pendrives, но я думаю, что должна быть какая-то опция сброса, которая работает эффективно на SSD без очистки всего устройства. В любом случае, если вы хотите протестировать, вы можете попробовать его, а затем создать новую таблицу разделов и раздел ext4 . См. Эту ссылку

help.ubuntu.com/community/mkusb/wipe#Wipe_the_whole_device

    
ответ дан sudodus 24.05.2017 в 19:53
1

Я хотел добавить один комментарий в ответ на отличный пост by @sudodus, но я по-прежнему в настоящее время 4 представителя, застенчивый от возможности прокомментировать, поэтому придерживайтесь его здесь:

Что касается оставления вещей в режиме ожидания - с технологией eMMC, над которой я работал (опять же, должен быть схожим, но не идентичным вашему), это не сработало бы, так как устройство должно было предположить, что разработчики системы могут сократить основную мощность и оставите только мощность IO.

На самом деле существует режим ожидания для координации энергосбережения, но я помню, как поставщики eMMC заявили, что не хотят просто запускать фоновые операции в середине времени, они запускают только эти операции типа очистки между принимая команду, которую вы ее отправили, и перед возвратом статуса (результата).

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

    
ответ дан Starman 02.06.2017 в 20:37