Кажется, моя SD-карта работает медленно. У меня есть карта ADATA 16 ГБ SDHC класса 10. Я проверил список совместимости, в котором перечислены карты с аналогичными характеристиками, и там указано, что она «работает». Даже простые задачи, такие как получение списка каталогов в небольшом каталоге, могут занять несколько секунд при первом запросе. Могу ли я использовать какие-либо инструменты, чтобы проверить, какую производительность я получаю с моей SD-карты? Кроме того, могу ли я внести какие-либо изменения в конфигурацию, чтобы SD-карта реагировала быстрее?

Я использую Raspberry Pi в качестве безголового ящика BitTorrent , поэтому все, с чем я сталкиваюсь - это просто запуск из командной строки. Я использую разделение 240/16, чтобы обеспечить максимальный объем доступной памяти.

Обновления

После выполнения некоторых тестов, которые @Krzysztof Adamski рекомендовал с помощью «dd», я получил хорошие результаты, получив скорость чтения 20 МБ / с и скорость записи около 10 МБ / с. Тем не менее, он все еще имеет проблемы со скоростью ввода-вывода. При тестировании я запускал команды "dd" в фоновом режиме и запускал top, чтобы посмотреть, что происходит. Я заметил, что процесс "mmcqd" занимал довольно мало места в процессоре, между 5% и 10%. Я посмотрел в Интернете и обнаружил, что многие люди сообщают, что «mmcqd» использует довольно много ресурсов процессора. Затем я выполнил следующую команду, чтобы проверить чтение и запись одновременно

sudo dd if=/dev/mmcblk0 of=test.dat bs=1M count=1024

При выполнении этой команды я получил пропускную способность всего 977 кБ / с, и «mmcqd» сообщил об использовании процессора между 10% и 25% каждые 5–10 секунд, после чего он уменьшился до нуля. Итак, я сделал еще несколько испытаний. Я выполнил следующие две команды в фоновом режиме, а затем посмотрел, что происходит сверху.

sudo dd if=/dev/mmcblk0 of=/dev/null bs=1M count=1024 &
sudo dd if=/dev/zero of=test.dat bs=1M count=1024 &

В этом случае "mmcqd" достигнет пика использования процессора примерно на 35%, но пропускная способность была намного выше - около 7,5 МБ / с для чтения и около 5,3 МБ / с для записи.

Кажется, что здесь происходит какая-то проблема, когда тяжелые записи приводят к тому, что "mmcqd" блокирует систему. Это заставляет демона передачи замедляться почти до нуля, как только скорость становится слишком высокой, пока он ожидает SD-карту. При работе с передачей-демоном я также вижу, что использование "mmcqd" становится довольно высоким

Скорость чтения карты тестирования:

Есть два простых способа проверить скорость чтения (список каталогов является только операцией чтения):

• используя команду dd:

  sudo dd if=/dev/mmcblk0 of=/dev/null bs=8M count=100

  Это будет считывать 800 МБ данных с вашей SD-карты и сбрасывать их в / dev / null. Если это занимает много времени, вы можете изменить count = 100 на count = 10, чтобы прочитать только 80 МБ. После завершения команды она должна напечатать сообщение со скоростью чтения. Вы должны получить как минимум пару МБ / с.

• используя команду hdparm:

  sudo hdparm -t /dev/mmcblk0

  Это должно дать вам тот же результат скорости, что и первая команда, а также должно быть не менее пары МБ / с.

Скорость записи карты тестирования:

Нет простого способа проверить скорость записи, так как для этого вам действительно нужно записать некоторые данные на карту. Если вы хотите сделать это на низком уровне (без файловой системы), вам придется переопределить некоторые данные на карте, и вы, вероятно, не хотите этого делать. Это можно сделать, если у вас есть раздел подкачки, так как его можно легко деактивировать (с помощью swapoff -a), протестировать с помощью dd (с помощью dd if=/dev/zero of=/dev/{yourswappartitionnanehare} bs=8M count=25), а затем создать заново (с помощью mkswap /dev/{yourswappartitionnanehare}).

Если у вас нет раздела подкачки, вы можете проверить скорость записи в файловой системе, используя команду dd:

dd if = / dev / zero of = / home / pi / testfile bs = 8M count = 25

Это создаст 200 МБ файл в /home/pi/testfile. Вы можете использовать любое другое имя файла.

Заметки:

• Во время тестирования убедитесь, что в вашей системе не запущены другие программы (например, торрент-приложения и т. Д.).
• После тестирования вы можете проверить вывод dmesgкоманды, чтобы увидеть, есть ли какие-либо сообщения о подсистеме mmc.
• Убедитесь, что у вас установлена ​​самая последняя версия прошивки. Есть патчи независимо от скорости SD-карты время от времени.
• Вы также можете проверить некоторые старые прошивки, так как могут быть некоторые регрессии. Самый простой способ сделать это (но не самый лучший) - это протестировать разные образы системы, построенные на разные даты. Сложнее всего использовать github и извлекать исторические версии файлов прошивки.

Для производительности SD-карты очень важно, является ли доступ последовательным (как с dd) или произвольным доступом в маленьких блоках. Карты SD, особенно высокого класса, похоже, оптимизированы для последовательного доступа, что хорошо для хранения фотографий или видео. Однако для запуска ОС на SD-карте более важен произвольный доступ, так как множество мелких файлов читается и записывается. Я полагаю, что bittorrent также генерирует несколько случайных обращений.

Эти две темы обсуждения содержат множество тестов SD-карт и обсуждений. В целом, скорость произвольной записи оказалась решающей для скорости запуска ОС карты. Эта скорость часто намного ниже, чем скорость последовательной записи, то есть скорость, которую производители хотели бы сообщить. Класс SD-карты основан на последовательных скоростях, и более низкие классы (4 или 6) могут фактически быть более подходящими для использования малины.

Инструмент iozone измеряет скорость многих моделей доступа. Я разместил краткие инструкции по компиляции iozone на малине здесь .

Что касается встроенного слота RasPI, то на сайте RasPI существует огромное обсуждение: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

Не было времени прочитать все 12 страниц обсуждения, но, похоже, проблема с сигналом CLK.

Вы пишете "bittorrent", и это вызывает мое предположение / ответ.

Торрент-протокол получает пакеты в случайном порядке от случайных сеялок.

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

Из того, что я знаю о SDCARD, его FAT / FAT32 и еще хуже для обработки фрагментации.

Поэтому найдите способ дефрагментировать вашу SDCARD или скопировать из нее все файлы, а затем переустановить ОС.

И наконец, написание LOT (как это делает движок bittorrent) порвет вашу SDCARD быстрее, чем при обычном использовании. Я не говорю, что это неправильно, потому что я сам считал это похожим. Но - это может быть причиной вашей проблемы.

Мне бы хотелось, чтобы был торрент-клиент, который автоматически передавал / перемещал загруженные файлы в другое место назначения после завершения загрузки + «зарезервированное время загрузки».

Тогда дефрагментация пошла бы намного быстрее.