Я использовал QEMU система для создания программного обеспечения. Проблема, с которой я столкнулся, заключается в том, что система, похоже, страдает от чрезвычайно медленный доступ к диску. Это не обязательно проблема, так как это не очень трудоемкая операция, но я бы хотел, чтобы она работала как можно быстрее.
Вот все, что я сделал, чтобы ускорить ввод-вывод:
KVM включен. Это разница между днем и ночью в том, что касается эмулируемой скорости процессора.
Qemu запускается с -display none режим через перенаправленный порт SSH, поэтому нет эмулируемого отображения SDL, потребляющего циклы процессора.
Виртуальные жесткие диски монтируются с -o noatime,nodiratime чтобы сократить количество ненужных записей.
Образы жестких дисков (8 и 12 гигабайт соответственно) имеют формат qcow2 и были созданы с помощью -o cluster_size=2M (это максимум - по умолчанию 65 536 байт). Сказал страница руководства: "Меньшие размеры кластера могут улучшить размер файла изображения, тогда как кластеры большего размера обычно обеспечивают лучшую производительность. "
Файловая система EXT4 с -o extents вариант, который страница руководства претензий "- это гораздо более эффективная кодировка, которая ускоряет доступ к файловой системе, особенно для больших файлов. "
В образах виртуальных дисков нет хранимых снимков. Я не уверен, замедлит ли это их, но похоже, что замедлит; фактический размер файла изображения не растет когда записывается моментальный снимок, поэтому я предполагаю, что данные хранятся каким-то запутанным образом, что делает так, что моментальный снимок и «рабочий» диск будут совместно использовать кластер, пока он не будет изменен, а затем весь кластер 2 МБ копируется в новый пробел, то данные меняются. Гениально, но совершенно неэффективно.
Мой вопрос: есть ли что-то, чего мне не хватает для повышения эффективности жесткого диска, или что помогало людям в прошлом, чтобы достичь почти естественной скорости ввода-вывода.
Вот еще пара вещей, которые я заметил:
Когда я подключаю жесткий диск к виртуальному хосту с -o sync система замедляется спуск. Мне это кажется нелогичным, поскольку записи на виртуальный жесткий диск, который является просто файлом на моем реальном жестком диске, уже перед записью буферизуется в ОЗУ. По сути, это двойная буферизация на диск с использованием вдвое большего объема оперативной памяти, чем необходимо. Резкое ускорение особенно странно с тех пор, как grep ^Dirty /proc/meminfo никогда ничего не говорит больше 1 МБ.
Кажется, что виртуальная машина отказывается использовать своп, если я не установил "swappiness" (/proc/sys/vm/swappiness) до 90 или выше. Хотя я согласен, что это, вероятно, хорошая вещь с точки зрения дискового ввода-вывода, она заставляет процессы сборки «бороться» с буферизацией fs за использование ОЗУ. Да, я уверен, что оперативной памяти достаточно.
Некоторые советы по производительности здесь, вам обязательно следует попробовать использовать необработанный формат вместо qcow2 и необработанные устройства вместо файлов изображений. Вам также следует установить паравиртуализированные драйверы диска на гостевых компьютерах и переключить тип диска с IDE на virtio.