[SOLVED]Скорость работы приложений.
Заранее извиняюсь за непонятное название. Как лучше сформулировать не знаю.
История проблемы:
Вся система лежит на SSD, кроме пары каталогов. В качестве /home примонтирован 2Гб винт(smartctl -a /dev/sdb1)
Суть проблемы: все работает, в принципе, хорошо, но. Когда я запускаю программу, работающую с винтом, она поначалу задумывается. В зависимости от размерой информации. Почтовик к примеру. Подвисает где-то на минуту(запуск mc при зависании), потом просирается и работает на «ура»(запуск mc без зависания). Как это можно исправить? /подвисание конкретно mc при первом запуске порядка 7 секунд/
До этого в качестве /home стоял винт на 500 Гб то ли Seagate и такого не наблюдалось.
Проблема вылезла сразу как я подключил этот винт (когда копировал на него информацию): когда заходил в каталог куда он примонтированн mc так же подвисал.
Проблема не в DNS
hdparm -tT /dev/sdb1
https://bpaste.net/show/87251ad7127c">fdisk -l /dev/sdb1
tune2fs -l /dev/sdb1
P.S. модератор я не знал куда это посместить, поэтому кинул в этот раздел. Если есть более подходящий - переместите плз.
UPD. вчера когда переразбивал винт сделал на другой 2хтеррабайтник dd if=/проблемный винт/sd** of=/винт на замену/sd** перед этим полностью скопировав таблицу разделов.
Сейчас воткнул вместо проблемного винта второй. Проверил - да, mc запускается чуть-чуть долговато. Но, видимо, потому что винт получает информацию о содержимом $HOME (было слышно как винт работает). Но хадержка была буквально секунды 2, не больше.
Может быть пролема как раз в том, что мой "проблемный" винт долго считывает информацию таблицы каталогов (или как это правильно называется, поправьте меня, пожалуйста)?
UPD. 2 Не знаю с чем это связано... но после перевода диск в формат GPT все стало относительо нормально. Задержка запуска mc ~1 секунда, что уже приемлемо. Всем спасибо.
- Для комментирования войдите или зарегистрируйтесь
дай угдаю - WD green 5400 ?
дай угдаю - WD green 5400 ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Таки нет. WD Red 5400. Или
Таки нет. WD Red 5400.
Или это одна фигня?
в выхлопе smartctl есть модель, если нужна.
По сути одно и то же, ведь
По сути одно и то же, ведь все упирается в скорость вращения шпинделя.
А надо бы вот так:
fdisk -l /dev/sdbА то вдруг там разделы не aligned, у WD с этим проблемы были одно время.
Вот-вот...
Раз переход произошел на бОльший объем, да еще и более 1ГБ, однозначно, необходимо проверить выравнивание разделов, очень похоже.
Ну и про green не зря вспомнили - сам чертыхался, но симптомы были другие - они просто умирали, скрипя и звеня. Так что - параметры ухода в ждущий режим тоже неплохо было бы проверить.
Исправил
Исправил
5400 это диагноз ;)
5400 это диагноз ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Решено-то решено, но
Решено-то решено, но кто-нибудь может объяснить природу наблюдаемого? Вопрос в целях ликбеза.
На мой взгляд - не решено.
В топике указано, что это еще и напрямик зависит от размера информации, запрашиваемой с /home. То есть, если я верно понял, LibreOffice склоняет к технологическому перерыву с дремотой. :)
Для вашей машинки (кстати, поподробнее бы о ней) такие задержки, на мой ненавязчивый взляд, совершенно неприемлемы.
Ну, повторюсь, у меня под
Ну, повторюсь, у меня под рукой оказался 2Тб от Сигейта. Когда я туда скопировал таблицу разделов через fdisk, а потом и сами разделы через dd и воткнул на место проблемного винта - задержки сильно уменьшились.
Что интересует измашинки?
dmidecode -t baseboard
https://bpaste.net/show/2559cc9a659d">cat /proc/cpuinfo
ну и просто dmidecode
lspci
И наблюдавшаяся проблема была с самого начала. С момента первого включения. Так что крайне сомнительно, что это симптомы умирания.
Прежде чем говорить о
Прежде чем говорить о симптомах, надо бы увидеть
.
dmesg| grep sd hdparm -vi
dmesg| grep sd
hdparm -vi /dev/sdb
smartctl -a /dev/sdb1 я выкладывал в шапке.
но имеет ли смысл, учитывая что сейчас монтируется диск в gpt-формате и та большая задержка ушла?
Тебе решать...
Тебе решать... но не ты ли задал вопрос?
Да и не только у меня есть мнение...
Но может быть ты и прав в сложившейся ситуации... поскольку в предоставленной тобой информации ничего подозрительного нет, а для дальнейшего исследования надо бы вернуться к проблемной конфигурации...
Ну про выравнивание разделов
Да, я. И до сих пор интересно. Уж больно непонятно найденное решение.
Ну про выравнивание разделов я писал - было выровнено (приведены выхлопы для варианта до перевода диск в gpt):
fdisk -l /dev/sdb
Я смогу вернуться, если на днях буду систему менять (если напишете что еще проверить на дефектном варианте - проверю). Пока, сами понимаете я не настолько исследователь чтобы террабайты туда-обратно гонять :)
Значит и начинать нужно сначала.
О! Значит и начинать нужно сначала. Посмотреть, как ведет себя винт с MHDD (можно загрузиться с RescueCD), понаблюдать скоростные характеристики и процесс инициации. ИМХО, все будет без задержек. Это будет проверка ниже файловой системы.
Потом загрузить gentoo с того же RescueCD, смонтировать винт и пообщаться с ним на предмет задержек. Это будет проверка на уровне файлововй системы.
Странный способ был выбран для перенесения данных - dd. Чересчур брутально. Вспоминается случай, когда чел пытался iso-образ посредством dd записать на флэшку и возмущался, почему флэшка не становится загрузочной . :)
За хар-ки аппаратуры спасибо.
Однозначно на таком железе можно ожидать комфортной работы (при достатке RAM, конечно).
P.S. Еще интересно - а если от рута залогиниться, то задержка при запуске mc такая же?
Эм. Боюсь я не настолько
Эм. Боюсь я не настолько железячник, чтобы знать куда смотреть :-( Разве что расскажете.
Проверка на уровне файловой системы показывает разницу: разбито через mbr - есть задержка, разбито через gpt - задержка в разы меньше.
Странный. каюсь, протупил, ибо вместо 0,8Тб, он мне копировал каждый сектор. На другой раз делал уже через cp.
RAM более чем достаточно - 16Гб. Учитывая, что при старте системы у меня отожрано только 400 с чем-то Мб, то ее более чем достаточно :)
От рута тоже самое. В консоли в свое время проверял.
...
Ниже файловой системы - это скорость обращения к секторам напрямую. Грузимся с RescueCD, выбираем "Run system tools from floppy disk image", затем "MHDD - Low level hard drive diagnostic tool". После выбора винта жмем F4 и снова F4. MHDD будет читать каждый сектор и рисовать карту скорости доступа к нему.
Кстати, для нормального опознавания винта в MHDD зачастую приходится устанавливать в BIOS режим обращения IDE или совместимый. Я много раз эксперементировал с этими режимами и сделал вывод, что на скорость работы Gentoo данная настройка не влияет совсем. Windows загружается только в том режиме, в котором установлена, но, на скорости работы, опять же, режим не отражается.
Хотелось бы узнать результаты выше файловой системы под управлением сторонней ОС, например - тот же RescueCD, там собрана Gentoo со всякими примочками.
Всё-таки жутко смахиват на
Всё-таки жутко смахиват на невыровненные по физическим блокам разделы.
Современные версии fdisk и gparted вполне себе делают правильно. То есть, первый создаваемый раздел начинается с 2048 сектора и уже выровнен (раньше fdisk начинал это делать с 63, если мне не изменяет память). Ну и другие тоже на начинаются с кратных 2048.
FYI
FYI: http://www.gentoo.ru/node/29001#comment-215628
Не факт.
В этом случае тормозня была бы при любых дисковых операциях с большим винтом. И это бы раздражало куда больше. :)
Не представляю как, но...
Не представляю, как это может быть связано с переходом /home на большой винт, но ... возможно дело вовсе не в нем, ибо - от рута такая же картина (!)... Стоит сделать fstrim для разделов на SSD?! Раз уж это с момента первого включения. Это скорее мысли вслух. :)
Вобщем, ждем результатов проверок ниже и на уровне ФС со сторонней ОС. Кстати, нехудо было бы такие же проверочки сделать и для SSD.
А fstrim все же попробуйте. "И кислород, и ванны..." :))