Производительность HDD
delvin 27 декабря, 2015 - 18:52
Приветствую всех. Суть вот в чем: частенько при переключении между задачами, винт начинает бешено сваповать. От 1-ой до 300-от секунд. Конфигурация немного "не того" конечно. BIOS на материнке Н55Н-М "не дал" установить загрузчик(ни Lilo ни Grub - выдают ошибки) в режиме ICH. В IDE-mode работает посредственно.
Собственно о винте, он "ноутбучный":
hdparm -i /dev/sda
/dev/sda:
Model=ST320LT020-9YG142, FwRev=0001SDM1, SerialNo=W046SK0H
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
Тест показывает:
hdparm -tT /dev/sda /dev/sda: Timing cached reads: 7292 MB in 2.00 seconds = 3650.74 MB/sec Timing buffered disk reads: 182 MB in 3.26 seconds = 55.75 MB/sec
Комп:
cat /proc/cpuinfo |grep name|sed q
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
free -h
total used free shared buffers cached
Mem: 1,8G 1,7G 113M 308M 10M 386M
-/+ buffers/cache: 1,3G 511M
Swap: 3,8G 1,3G 2,6G
dmidecode
Base Board Information
Manufacturer: ECS
Product Name: H55H-M
Version: 1.0
Serial Number: 00000000
Asset Tag: To Be Filled By O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To Be Filled By O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Раздела три:
На указаном винте
1. Swap 4Гб
2. / остальное
на другом (WDC WD5000AAKS-00V1A0)
3. Home
Вопрос: Как бороться с пересвопом? Может какие "хитрые" параметры для hdparm есть?
Спасибо.
»
- Для комментирования войдите или зарегистрируйтесь
что такое "пересвоп" ? как
что такое "пересвоп" ?
как связана скорость i/o винта и hdparm ?
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 ;)
Это когда начинает маслать
Это когда начинает маслать так, что даже мышь подтормаживает. Очень выразительно выглядит горящий светодиод HDD и стоящая колом система на переключении, например, между GIMP и браузером с десятком вкладок.
А hdparm имеет много ключиков интересных. В старые времена UDMA4 режим включался вручную именно hdparm'ом на моем винте. "Автоматом" никак.
Делай, что должен и сбудется, чему суждено!
Linux 4.9.0 #2 SMP x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Mem: 4 Gb, VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT]
С браузером часто помогает
С браузером часто помогает смена chrome на firefox или что-то более экономичное )
Надо понять проблема в медленно винте или кол-ве памяти.
Если проблема в кол-ве памяти, то проще и эффективнее докупить оперативки.
Можно попробовать поиграться с параметром swappiness или поэкономить память или сжать своп и память (zram zcache и т.д.)
но кардинально поможет либо увеличение памяти либо ssd винч
.
В рамках существующей Сети утверждение оптимистичное.
Лисичке очень помогает выключение JavaScript.
:wq
--
Live free or die
Скорее и то и другое
Винт уж очень медленный. Если своп накопился менее 1Гб(из 4-ех), то отзывчивость выше. Ядро собирал lowlatency именно из-за винта (HDD 320 Gb SATA-II 300 Seagate Momentus Thin < ST320LT020 > 2.5" 5400rpm 16Mb). Оперативы тоже мало - 2Гб.
Браузер Vivaldi(если не держать по 12-20 открытых вкладок, как у меня, то очень резвый).
Увеличение памяти и уж тем более замена HDD не грозит по финансовым причинам.
Может ядро 4.2.6 как оптимизировать можно?
P.S: Была идея накатить 2.6.* ядро, но побоялся несовместимости.
Делай, что должен и сбудется, чему суждено!
Linux 4.9.0 #2 SMP x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Mem: 4 Gb, VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT]
Как я уже писал можно
Как я уже писал можно попробовать ускорить за счет сжатия свопа и памяти (zram zcache и т.д.) и ukms
Оптимизация не ускорит винт и не увеличит память, магических опций нет или они включены по дефолту. Что бы убедиться, что проблема не в кривом конфиге ядра загрузись и поработай с livedvd/livecd, если там будет лучше, то будешь копать в сторону того, в чем разница.
ps у меня на работе ноут: после того как перенес систему на squashfs стало заметно быстрее
эффект от сжатия оперативки и ukms оценить сложно, но вроде есть. Правда их эффект тем больше, чем больше памяти, а ее у вас мало (
Не вариант.
squashfs не вариант, видимо. Слишком много софта запускается одновременно - памяти не хватит.
Думаю не мудрить и перенести систему на WDC WD5000AAKS-00V1A0. И скорость на шпинделе выше и диаметр больше, а значит векторная скорость выше.
...и придется, видимо, к 23-ему разоряться на вторую планку.
Спасибо и с наступающим!
Делай, что должен и сбудется, чему суждено!
Linux 4.9.0 #2 SMP x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Mem: 4 Gb, VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT]
Частично.
Вопрос частично решился переводом swap на WDC WD5000AAKS. По крайней мере 18-20 вкладок в браузере не "вешают" комп. Но проблема не исчерпана до конца. emerge-webrsync "вешает" почти наглухо, поэтому прописал его в крон на 5 утра :)
Делай, что должен и сбудется, чему суждено!
Linux 4.9.0 #2 SMP x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Mem: 4 Gb, VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT]
Чтобы работа с портажем не
Чтобы работа с портажем не убивала все и вся, выдели
/usr/portageи/var/tmpв отдельные файловые системы (ЛВМ тебе в помощь!). В силу специфики организации портажа рекомендую для этих ФС использоватьreiserfs(старый добрый v3, а не новомодную поделку!). Eсли у тебя где-нибудь есть файлопомойка, то туда можно отделить/usr/portage/distfiles. Идеально было бы/var/tmpпосадить наtmpfs, но у тебя памяти маловато... хотя попробовать можешь, я думаю где-то 90% пакетов наверняка скомпилируются без проблем. У меня с 16Гб памяти только libreoffice и chromium не влезают вtmpfs. Для них я монтирую 16Гб логический диск для/var/tmpсreiserfs.Выгоднее
Выгоднее иметь /usr/portage в squashfs. Меньше места (в разы), больше скорость (также, в разы). Актуальный portage.sqsh занимает 97669120 байт.
А чем tempfs выгоднее ramfs?
Ага, а образ чем, из чего и
Ага, а образ чем, из чего и когда генерировать?! Мы же не о фиксированной сборке говорим. У меня портаж обновляется ежедневно, а в некоторых случаях и чаще.
2. Хотя бы тем, что не сожрет весь твой RAM! :) А подробности тут...
Образ и tempfs
Образ - имеется ввиду сам portage.sqsh? Запускается примитивный скрипт, он распаковывает в память (/var/tmp/portage) образ, синкает его с зеркала (опять же, в разы быстрее, чем на реальной ФС), пакует снова в squash, удаляет /var/tmp/portage, отмонтирует старый, бэкапит его, монтирует новый (это для возможности отката). Также, как и у Вас, это происходит каждый день. Раз в неделю все бэкапы, старше недели, удаляются. В make.conf установлена переменная DISTDIR в удобное место.
Удобно еще и тем, что все компы в локальной сети тупо берут сам squash-файл для обновления, без использования механизмов синхронизации. Ну, про скорость работы со смонтированным sqaush и действительно ощутимую экономию дискового пространства (и i-nod'ов на ext4, ибо она все же пошутрее reiserfs) уже писал, повторяться не буду.
Если tmpfs сожрет мой рам, то начнет свопиться. Т.е., начнет не выигрывать, а очень сильно проигрывать в производительности реальной FS (это при закончившейся-то памяти, к тому же!). Чего не будет наблюдаться с ramfs - она вытеснит в своп все остальное. Исходя из чего и была выбрана именно ramfs, а не tmpfs. Ведь если рама не хватает на полное размещение временных файлов, - эффективнее будет реальная, а не засвопленная ФС. Или нет?
1. Ага, я так и думал... И
1. Ага, я так и думал... И как это будет быстрее/меньше? :) Живой портаж - где-то пол-гига, в наше время это чуть больше, чем ничто, даже для домашних компов. Тем более когда он шарится для группы через НФС. Я уж не говорю о ситуации, когда ты обновишься во время обновления зеркала - портаж будет кривой. А я просто тут же обновлю еще раз... :)
2. Нет уж, у меня своп тмпфс запрещен! По мне так лучше пусть компиляция обломится, когда место закончится (я ей тогда дисковую версию подниму, если надо), нежели приложения начнут тормозить/ломаться...
Иногда лучше мысли практически проверять
1. Полгига - это размер файлов. А на диске сколько? Размер реального portage.sqsh 97566720 байт. Чудно себя чувствует на ext4. А насколько быстрее -
real 1m31.197s
user 1m44.580s
sys 0m33.210s
это выдала time на исполнение такого скрипта только что, на ноуте с частотой 1000 МГц и двумя ядрами, все время было потрачено на распаковку/запаковку.
А это time eix-update
real 0m31.431s
user 0m25.990s
sys 0m4.900s
Обратите внимание на sys - у меня дико тормозная дисковая подсистема. Сравните со своими, не стесняйтесь. И будьте уверены, Ваше время eix-update уменьшится как минимум на 20% (при сравнении с reiserfs выигрыш будет больше) после перехода на squash.
Не стараюсь навязать свое решение, не нужно так нервничать. Но попробовать стоит, "я гарантирую это". :)
P.S. Невнимательно прочитал Ваш предыдущий пост, в целом - согласен с Вами по второму пункту.
.
Полгига с учётом того, что роялит скорее размер ячейки файловой системы и количество файлов — примерно ниочём.
У меня с предпочтением… прямо скажу архаичных алгоритмов сжатия
squash-образ дерева (правда немного порезанного) — 85 мегабайт.Что вполне совместимо даже с скромными двумя гигами рамы.
:wq
--
Live free or die
.
Меньше.
(синхронизация от сего дня)
:wq
--
Live free or die
.
aufsИбо обновляемость.:wq
--
Live free or die
Мысль здравая.
Вот только с 2004-ого года я ни разу не удосужился сделать
man 8 lvm:(Есть, 100Гб на ВДшке под ext4.
Думал, покурю маны.
Спасибо!
Делай, что должен и сбудется, чему суждено!
Linux 4.9.0 #2 SMP x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
Mem: 4 Gb, VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT]