LinuxForum.Fans
Тема

Низкая скорость дисков

Автор: Cruiser78 7 сообщений 3903 просмотров
#187569

Привет всем!

Возникла проблема.
1. Есть интеловский сервер с RFR-13, на котором реализован аппаратный RAID-1.
2. Симптомы - наблюдаю низкую скорость работы дисковой подсистемы, скорость копирования большого файла (порядка 600Mb) составляет порядка 2-3 мегабайт в секунду. При этом (mc показывает) начало файла ( менее 200 мб) копируется быстро, точнее с нормальной скоростью (40-50мб). Типа как в кэш заносится, а потом кэш переполняется и запись на диск становится колом (2-4 мб/с).
3. На аналогичном (аппаратно) сервере такого не наблюдаю (ось - RFR-12), Там такие файлики копируются шустро. Работа кэша видна, но не так явно.
4. SMART на дисках не криминален. По трактовке palimpset и smartctl - диски в порядке.
5. Скорость чтения на проблемном сервере - стабильно высокая.
[console]# hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 348 MB in 3.00 seconds = 115.91 MB/sec
[/console]
Однако при операциях чтения/записи iostat показывает очень высокое значение iowait\а. До 100% может доходить. На аналогичном сервере такого нет.
6. Хотел проверить производительность записи в palimpset, но так как диски райдовские - вариант обломился. К тому же - вычитал, что тестирование записи palimpset делает только на полностью чистых, сырых, без файловой системы, дисках.
Q. Разве операция проверки записи - разрушает данные?
Ведь что мешает прочитать сект ор в буфер, протестировать сектор, а потом восстановить его первоначальное содержимое...
Теперь вот боюсь проверять скорость записи на моих дисках... Как бы система не рухнула. Или на воду дую?

Коллеги, подскажите, где могла собака зарыться и как её правильно откопать?

#187573

http://yandex.ru/yandsearch?text=12309&lr=2
не?

Cruiser78 написал:
Q. Разве операция проверки записи - разрушает данные? Ведь что мешает прочитать сект ор в буфер, протестировать сектор, а потом восстановить его первоначальное содержимое...

скорость. вы-же скорость ЗАПИСИ хотите померить, а не скорость чтения-записи-перезаписи.

#187580
drBatty написал:

Может и оно. Если оно - то это засада... Переустанавливать сервер не хочется совршенно. Главное, что вылезло через полтора года беспроблемной работы...

drBatty написал:
вы-же скорость ЗАПИСИ хотите померить, а не скорость чтения-записи-перезаписи.

Нет, немного не так - мой спич был о том, что я не вижу никаких технических проблем для проведения неразрушающего тестирования записи. А не тупо заливать диск нулями и мерять скорость этой заливки. И вот есть диск с данными и есть желание проверить скорость записи на нём. И нет информации - palimpsest разрушает информацию или нет?

#187590
Cruiser78 написал:
Может и оно. Если оно - то это засада... Переустанавливать сервер не хочется совршенно. Главное, что вылезло через полтора года беспроблемной работы...

ага. так оно и бывает.
По моему мнению, 12309 это проблема с памятью. Купите ещё памяти, либо постарайтесь её освободить. Я про оперативную память (RAM). Только не спорьте - я проверял на практике. ИМХО новые ядра оптимизированы в расчёте на нормальный объём памяти.

Cruiser78 написал:
Нет, немного не так - мой спич был о том, что я не вижу никаких технических проблем для проведения неразрушающего тестирования записи. А не тупо заливать диск нулями и мерять скорость этой заливки. И вот есть диск с данными и есть желание проверить скорость записи на нём.

вы не понимаете: HDD это вам не кусок линейной плёнки. HDD это очень сложное устройство со сложным алгоритмом работы. И померить его скорость РЕАЛЬНО можно только тупо заливая инфу на него. Если делать по вашему алгоритму, результаты измерений будут различаться в разы, в зависимости от погоды на Марсе, а потому будут бесполезными.

Если вы не видите технических проблем - это не значит, что их нет. Основная проблема даже не в том, что диск разделён на цилиндры и сектора, а в том, что это разделение скрыто, и никакими методами недоступно. Логическое представления диска (с 255ю головками) не имеет никакого отношения к действительности. А что там физически - неизвестно.

Вы будете записывать инфу, но вы точно не знаете, куда и как она ляжет. Будет-ли позиционирование головок при копировании? да/нет? Если будет - скорость упадёт в 1000 раз. В итоге, в 10 раз более быстрый диск может показать результат в 1000 раз хуже. Кому нужен такой "тест"?

#187605
drBatty написал:

ага. так оно и бывает.
По моему мнению, 12309 это проблема с памятью. Купите ещё памяти, либо постарайтесь её освободить. Я про оперативную память (RAM). Только не спорьте - я проверял на практике. ИМХО новые ядра оптимизированы в расчёте на нормальный объём памяти.

С этого и начнем. У меня там, действительно памяти немного. Всего 2 гектара. Правда и свистопределок практически нет. Хотя... Там и drbd и glusterfs живут. Однако:
[console]# free
total used free shared buffers cached
Mem: 2053668 1918568 135100 0 126872 683168
-/+ buffers/cache: 1108528 945140
Swap: 5119996 53348 5066648
[/console]
Не вся память исчерпана и в свопе мало что лежит...

#187607
Cruiser78 написал:
Не вся память исчерпана и в свопе мало что лежит...

как не странно, но 12309 проявляется ДО исчерпания памяти.
При самом подходе к исчерпанию наступает OOM Killer. И вы уже близко к этому.
Вообще-то, free даёт мало информации, куда как полезнее информация (h)top.

#187616
drBatty написал:
Вообще-то, free даёт мало информации, куда как полезнее информация (h)top.

Да там, в принципе, по общему распределению памяти - тоже самое...

Войдите или зарегистрируйтесь, чтобы ответить.