Как и в предыдущем вопросе, использует ли 7zip (точнее p7zip на Linux) дисковое пространство при тестировании архивов? Поскольку у меня есть только диск на 2 ТБ для работы и каждый архив имеет размер от 800 ГБ до 1 ТБ, я подумал о тестировании 2 архивов одновременно, а не одного.
В официальной документации 7zip не упоминается об использовании диска во время тестирования.
решение1
Этого не должно быть. (Но это может быть)
Чтобы проверить правильность данных в архиве при их извлечении, каждый файл или блок данных будет иметь связанный с ним CRC или код обнаружения ошибок.
При распаковке файла имеет смысл, с точки зрения эффективности, выполнить проверку на наличие ошибок.дозапись данных на диск. В противном случае вы тратите драгоценные ресурсы на чтение из архива, запись его на диск, а затем повторное чтение данных на диске для проверки ошибок. При большом архиве или в системе с ограниченной памятью это может удвоить время, необходимое для распаковки файла, что неприемлемо. Я предполагаю в этом случае, что чтение и запись на диск являются самой медленной частью процесса.
Если вы делаете проверку перед записью, вы можете эффективно пропустить архив через декомпрессор, через ваш алгоритм проверки ошибок, а затем на диск и предположить, что дисковая подсистема знает, что она делает. Работа сделана.
Делая это таким образом, «тестирование» архива становится бесплатной операцией. Вы выполняете точно такие же шаги, как и при распаковке, но вы просто выбрасываете данные, не записывая их на диск.
Я очень надеюсь, что это так и работает, потому что запись всего на диск просто для проверки архива кажется безумием и будет не быстрее, чем «реальная» распаковка данных. То, что «тестирование» быстрее, подразумевает, что по крайней мере один шаг, скорее всего, запись данных на диск, пропускается.
решение2
Нет, не соответствует, по крайней мере, версия от 19.00.
Параллельное тестирование нескольких файлов отлично работает на твердотельных дисках, но обычно убивает производительность на механических дисках - тогда требуется много поиска для параллельного чтения нескольких архивов. Таким образом, можно дать следующую рекомендацию:
При тестировании архивов на твердотельных накопителях (NVMe или SATA SSD) запускайте столько процессов, сколько у вас ядер (если это возможно).
При тестировании архивов на одном механическом диске (или механическом томе RAID) запустите один или максимум два процесса.
При тестировании архивов на USB-накопителях результаты будут отличаться.
Печальное большинство обычных USB-накопителей или «флешек» ужасно медленные, даже при чтении, т. е. далеки от насыщения полосы пропускания интерфейса USB. Некоторые такие накопители становятся еще медленнее при доступе к данным из нескольких разрозненных областей накопителя одновременно. Это вызвано ограниченным объемом оперативной памяти в контроллере диска. Контроллер не может вместить все метаданные, необходимые для доступа ко всему накопителю, в оперативную память одновременно, и в конечном итоге будет перечитывать метаданные с флэш-носителя, поскольку он изменяет области чтения на накопителе, часто вынужденный следовать цепочкам ссылок, чтобы найти их. Такие чтения метаданных часто не распараллеливаются накопителем, даже если бы это позволяла структура флэш-памяти, и часто также реализуются с использованием выделенных путей кода, которые просто медленные.
Единственный надежный способ справиться с этим — провести тест пропускной способности. Предположим, вам нужно проверить архивы a, b, c, d, eи f, все примерно в одном порядке величины по размеру. Их нужно отсортировать по убыванию размера. Сначала засеките время проверки aи вычислите пропускную способность BW_a = time_a / size_a. Затем выполните проверку bи cпараллельно и вычислите эти пропускные способности. Пока их сумма sum_BW_bcбольше BW_a, вы получаете прирост производительности. Затем проверьте d, eи fпараллельно и вычислите эти пропускные способности. Пока их сумма sum_BW_defбольше sum_BW_bc, вы получаете прирост производительности. И так далее. В конце концов вы достигнете количества потоков, при котором общая пропускная способность упадет по сравнению с предыдущим тестом. Продолжайте проверку оставшихся архивов, используя предыдущее, меньшее количество потоков.
Этот метод можно применять к любому диску, хотя падение производительности механических дисков настолько резкое, что может неоправданно повлиять на общую производительность процесса проверки. Из-за этого параллельные тесты следует прекращать, когда становится известно, что их пропускная способность составляет менее 90% от пропускной способности предыдущего шага. Это можно сделать, пересчитывая пропускную способность каждую секунду выполнения теста и прекращая тест, когда пропускная способность опустится ниже точки отсечки.