У меня есть набор больших файлов, которые я иногда копирую между ящиком Linux и ящиком Windows. Размер каждого файла составляет около 2 ГБ, а их обычно около 10 (это образ виртуальной машины). Виртуальная машина работает в Linux (qemu), и я создаю резервную копию в Windows. В этом случае виртуальная машина не работает.
Когда я копирую файлы из окна Linux в ящик Windows, все работает нормально. Когда я копирую файлы из окна Windows обратно в Linux, я получаю аномально высокую и непрерывную загрузку процессора в Linux, и передача файлов идет очень (очень) медленно.
Я использую socat, lz4 и tar для переноса файлов. В окне Windows я использую cygwin для socat, tar и т.д. (но это не имеет большого значения, потому что окно Windows работает нормально). Я выбрал lz4, потому что он очень (очень) быстрый и (как gzip и т. Д.) Обеспечивает проверку.
Когда я копирую файлы из ящика Linux, команда Linux выглядит так: tar cvf - *vmdk | lz4 -B64 | socat - TCP-LISTEN:7777,reuseaddr и команда Windows socat TCP:linuxserver:7777 - > bigbackup.tar.lz4 . Это работает нормально, и я получаю от 25% до 100% использования сети, а загрузка ЦП во всех системах составляет менее 25%.
Когда я копирую файлы обратно в ящик Linux, команда Linux выглядит так: socat TCP-LISTEN:7777,reuseaddr - | lz4 -d | tar xvf - и команда Windows cat bigbackup.tar.lz4 | socat - TCP:linuxserver:7777 .
Когда я запускаю эту операцию восстановления, чтобы скопировать файлы обратно в свой Linux-сервер, передача работает, как ожидалось, в течение нескольких секунд, а затем передача начинает останавливаться и замедляться, а ЦП в Linux-системе начинает пикировать, а затем привязывается к 100%. , а все другие программы становятся менее отзывчивыми (а иногда и не отвечающими). Если я оставлю это в покое, передача в конечном итоге будет завершена, но примерно на 5% скорости, которую, как мне кажется, она должна была занять, при постоянном фиксировании ЦП.
Если я использую вкладку «Сеть» диспетчера задач Windows или linux gnome-system-monitor, сетевая история выглядит странно - от 2 до 5 секунд передачи данных при загрузке примерно 25%, а затем ноль в течение 30-40 секунд. Это повторяется до завершения передачи. ЦП на все время 100%. При использовании htop (linux) загрузка ЦП процессами socat и lz4 составляет от 0 до 2 процентов, а процесс tar иногда достигает 25%, но даже когда их сумма мала, какой-то неучтенный поток использует остальную часть ЦПУ. Я пробовал renice в процессе tar, но безрезультатно.
Если я запускаю процесс восстановления в другом окне (Windows) (с теми же командами), передача происходит плавно с использованием сети от 25% до 100%, как и при резервном копировании. К сожалению, у меня нет других Linux-систем для тестирования.
То, что эта проблема возникает, для меня так же ошеломляет, как машина, которая не может поворачивать налево по вторникам. Если диск в системе Linux останавливался из-за медленной записи (это SSD), я бы ожидал, что поток ядра просто заблокируется, оставляя процессор доступным.
Вот некоторая информация об оборудовании и системе.
Я просмотрел документацию для TAR, и, похоже, нет никаких флагов, которые управляют тем, как система должна записывать файл (например, буферизация, кеширование, синхронизация записи и т. Д.).
Кто-нибудь знает, почему это происходит, и есть ли способ исправить это или сделать менее эффективным?
В окне Windows вы пробовали отключить антивирусное программное обеспечение?
Вы также можете увидеть, что у вас получилось, с помощью wirehark.
Но похоже, что что-то из окна linux и окна окна не сходятся во взглядах, это может показаться глупым, но посмотрите, что происходит, когда вы загружаетесь в безопасном режиме с сетью в окне окна, и посмотрите, можете ли вы передать файлы, которые так или, по крайней мере, посмотрите, получите ли вы лучшие результаты. Если вы заметили, что скорость передачи данных выше, попробуйте выполнить чистую загрузку, чтобы выяснить, какая программа вызывает скачки ЦП.
Также убедитесь, что ваш интернет между двумя устройствами стабильный. (Если у вас медленная скорость интернета, это тоже может быть причиной)