Я начал разархивировать RAR-файл размером в несколько гигабайт. Компьютер сейчас работает очень медленно, он почти заморожен. Иногда я могу немного двигать мышью, но это все. Процесс разархивирования, кажется, остановился, и теперь все, что я могу сделать, это перезапустить систему. Я не думаю, что могу разархивировать этот файл в Linux.
У меня никогда не было этой проблемы в Windows. Как это можно исправить?
Замедление, вероятно, происходит из-за Айоваита. Команда ionice должна позволить вам продолжить работу:
команда ionice -c3
Попробуйте запустить команду с более низким приоритетом, используя утилиту nice . Распаковка больших файлов может потребовать много ресурсов ЦП, поэтому, как правило, это один из инструментов, используемых для измерения производительности в тестах и обзорах ЦП.
пример:
$ nice -15 ./myprogram
Указанное вами число является корректировкой уровня симпатии по умолчанию. -20 - самый высокий приоритет, а 19 - самый низкий. Отрицательные числа зарезервированы для пользователя root.
У меня тоже было такое же явление, но я думаю, что нашел ответ. Раньше я использовал unrar на 1 диске, для чтения и записи. Так как это много, у всех других процессов нет времени работать на диске. Теперь я позволю unrar помещать распакованные предметы на другой диск, а не в другой раздел, на другой физический диск. У этого есть несколько преимуществ:
Это простое решение, но оно работает.
У меня была похожая проблема с большим файлом .zip (1,4 Гб), который содержит почти 200 000 маленьких файлов. Мой Ubuntu 13.10 64 бит занял бы более 10 часов. Никаких зависаний, система на самом деле не тормозит, просто распаковка невероятно медленная.
Я попробовал решение для виртуальной машины, упомянутое выше, с Virtualbox и W7 64. Здесь приходит сюрприз:
1) сначала я поделился папкой с виртуальной машиной и попытался разархивировать ее там, в том же месте (виртуальный блок F: в W7) с 7-zip. Не повезло, такая же дерьмовая скорость, которая бы длилась вечно. 7-zip сообщил о начальном выходе 200 кбит / с, но он продолжал замедляться, пока я не остановил его (менее 100 кбит / с и ETA 7 часов, но, вероятно, он замедлился бы еще больше и занял бы гораздо больше времени).
2) затем я переместил файл .zip внутрь "жесткого диска" виртуальной машины (что vm считает жестким диском). Таким образом, файл не был в общей папке с Ubuntu. Сюрприз, сюрприз, он отлично работает, на скорости около 2000 Кбит / с, так что это заняло менее 15 минут.
3) в качестве примера, 32-битная система Windows 7 (не виртуальная машина) с точно таким же оборудованием заняла около одного часа со стабильной производительностью около 500 кбит / с, согласно 7-zip. Я понятия не имею, как изменение с 32 на 64 бита влияет на распаковку файлов, просто подумал, что было бы хорошо упомянуть, чтобы сравнить.
Ubuntu 13.10 64-битная с ext4, W7 с NTFS и 64-битная виртуальная машина и 32-битная нормальная система. Что меня действительно удивляет, так это тот факт, что W7 vm действительно использует лежащую в основе файловую систему ext4, потому что это vm и все еще достигает этих скоростей.
Я надеюсь, что некоторые гуру прочитают это и выяснят это, это чрезвычайно раздражает и интригует.
Я нашел решение. У меня виртуальная машина Windows уже установлена в Linux. Я поделился папкой, в которой находится архив с виртуальной машиной. Затем внутри Windows я разархивировал файл, используя 7-zip, и все прошло гладко. Это заняло много времени, но я не увидел заметной разницы в производительности системы. 7-zip недоступен для Linux. Окна все еще могут быть полезны иногда!
Разархивирование большого архива не должно быть проблемой, вы просто видите симптомы чего-то другого.
Ваш раздел Linux близок к своей емкости? Нравится 95% или больше? Если это так, то многие файловые системы (включая ext3, ext4 и reiserfs) будут работать намного медленнее.
В противном случае скорость ввода-вывода диска в Linux нормальная? Будут ли программы запускаться в разумные сроки, просмотр папок с помощью файлового менеджера будет быстрым или медленным? Вы пробовали какую-нибудь программу бенчмаркинга, такую как bonnie++ или ionice?
Распределяет ли разархиватор всю доступную память? Смотрите top , пытаясь разархивировать этот пакет.
Иногда планировщик дискового ввода-вывода cfq по умолчанию может привести к странным проблемам во время длительных всплесков активности диска. Вместо этого вы могли бы попробовать сроки или упреждающие планировщики. Например, крайний срок, как правило, достаточно хорош для рабочих нагрузок базы данных, поэтому он может работать и в этом случае.
echo deadline >/sys/block/sda/queue/scheduler
или же
echo anticipatory >/sys/block/sda/queue/scheduler
Замените sda на имя вашего жесткого диска.
Это будет временное изменение, и обычно я бы не советовал менять cfq при использовании на рабочем столе, но если у вас возникают другие проблемы с вводом / выводом, кроме этой разархивирующей вещи, это может стоить того. Если все это только потому, что unrar съел всю оперативную память ... :-)
Это, вероятно, потому что у вас недостаточно оперативной памяти. Вы можете перераспределить свой жесткий диск, чтобы включить большой раздел подкачки, но это все, AFAIK.