Linux 12309 УМВР?

lexa - 18/Июл/2011 13:44

Короче, докладываю:

  • Берем виртуальную машину (4Gb RAM, 200G диск, диск на относительно быстром массиве 6xSAS 7200 RPM, RAID6, типичные скорости I/O туда, если не слишком много потоков - 300-400Mb/sec). Разрешаем юзать все 8 "ядер" CPU (кавычки т.к. ядер 4 + HT)
  • Ставим туда OpenSUSE 11.4, x64, накатываем всех апдейтов. Ядро получается 2.6.37.6-0.5-desktop. Файловая система EXT4:
  • Делаем файло на 10Gb: dd if=/dev/urandom of=file bs=1024k count=10000, потому что с нулями непонятно что там накопирует.
  • И начинаем это файло копировать в соседей:
    for i in 1 2 3 4 5 6 7 8 9
    do
     cp file file-$i &
    done
И иногда оно получается: система встает раком минут эдак на несколько, не реагирует на кнопки и мыши. Более того, окошко в котором был запущен iostat тоже замирает и выяснить какое там IO не получается. Пока оно не замершее - ну нормальный такой IO, 220-300Mb/sec.

Увы, но IO в момент замирания с точки зрения хост-машины забыл посмотреть. Попытаюсь воспроизвести проблему еще раз, но позже.

Comments

kranov (not verified) - 18/Июл/2011 14:09

я бы после отмирания посмотрел free, используется своп али нет.

lexa - 18/Июл/2011 14:36

Я забыл и все нахрен уже выключил, не до грибов, вечером будет время - повторю

iskatel (not verified) - 18/Июл/2011 14:49

со свопом такой тест почти гарантированно даст такой эффект.
Просто потому, что память будет выжрана под кэши.

lexa - 18/Июл/2011 15:06

О!

А это верная мысль, что если у меня кого-то высвапило, а потом оно хочет проснуться, находит свои странички в свапе и тут то, при длинных очередях, и начинается это самое?

Тогда, получается, воспроизвести вообще очень просто:
- аллоцировать пару гигабайт, засрать их частично
- уснуть минут на 10, чтобы 10x cp запустилось
- потом проснуться и продолжить засирать гигабайты?

Гы!

iskatel (not verified) - 18/Июл/2011 15:27

Со свопом - да, очень вероятно.

lpauzner (not verified) - 19/Июл/2011 16:04

Если бы для файла открытого на чтение файловый кеш выгружался в свап - был бы совсем epic fail.

Проблема скорее в имплементации cp - оно же по сути как pipe, должно переставать читать когда длина очереди на запись становится больше какой-то (=< допустимый размер дискового кеша при имеющемся профиле памяти), и таким образом не усугублять проблему.

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

В виндоус граждане тоже жалуются на что-то похожее http://ctpeko3a.livejournal.com/506520.html

lexa - 19/Июл/2011 16:27

Не, кэш, понятно, в свап не выгружается. Ну то есть не должен бы. Но может вытеснить странички спящего приложения.

Причем, веселуха, по идее, может быть не столько от вытеснения, сколько от того, что у приложения что-то аллоцировано, но не используется (и потому отсутствует), а тут оно захотело его поюзать - а все пожрал кэш.

И идея иметь для cp специальный сисколл или вызов - она правильная, в виндах так и сделано. Но не cp же единой, скажем если я занимаюсь сортировкой (слиянием) терабайта данных в уголке - это тот же паттерн (несколько потоков чтения, один - записи) и те же грабли.

С виндой, как я уже писал в прошлом посте я на нечто подобное наступаю при heavy IO иногда (уже давно не было что-то) но с существенным отличием: замирание не полное, запущенные программы работают и даже файловый IO какой-то делают (браузер кэш пишет и все такое), проблемы с запуском новых процессов - это да. Правда до того, чтобы 700G писать по USB я не дохожу :), если больше чем гигов 30-40 на внешний диск, то я не поленюсь eSATA-крэдл достать.

Но симптомы у винды близкие по смыслу, да: память занимается близко к 100% (это из 12-16 гигов то), свапа у меня практически нет, потому его и нет, а на что ушла память и зачем - понять не удается.

lpauzner (not verified) - 19/Июл/2011 17:05

Про тот же паттерн я и говорил: если очередь на запись больше чего-то там (для каждого приоритета - отдельно!), то незаметно сделать запись блокирующей, и оно приостановит все что нужно.

Просто парадигма "памяти неограниченно, если что - виртуальной памяти нам хватит" она в ряде ситуаций очень misleading.

Учитывая то, как люди оптимизируют strlen 8-)
http://en.wikipedia.org/wiki/Strlen#cite_ref-bsd9xstrlen_1-0
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/strlen.c?rev=1.10
хотелось бы ожидать что работа с дисковым кешем давно доведена до совершенства для всех мыслимых профилей использования.

lexa - 19/Июл/2011 21:39

Хрен с ним со strlen, они и memcpy оптимизируют!.

А по сути проблемы:
1) понятно что нужен полезен какой-то fcntl вроде madvise, который будет говорить "в этот хэндл будут только писать, большими блоками, перематывать в начало и переписывать не будут". Тогда, понятное дело, можно это место агрессивно не кэшировать, все едино смысла нет.
2) Насколько частым является паттерн(ради которого имеет смысл именно агрессивное кэширование) когда пишущий процесс возвращается назад по файлу и кусочки переписывает - этого я не знаю. Ну, понятно, типичный SQL-сервер таков, но он сам кэширует и сам fsync делает.

FreeBSD сейчас тоже замучаю. Уверен что не замерзнет (иначе бы все время замерзала с моими мувами BD-movies), но тоже ведь интересно...

lpauzner (not verified) - 19/Июл/2011 23:31

1) подобная семантика вообще-то называется сокетом. В частном случае cp есть даже аналог - sendfile. Но это не совсем про диск, хоть и близко.
2) мне казалось что память в основном расходуется на кеширование прочитанного - вдруг кому понадобится? Кеширование же записи в основном имеет смысл в небольших количествах, для сглаживания нагрузки на диск, в надежде что очередь рассосется раньше чем пополнится вновь. Если же очередь на запись бесконтрольно удлиняется то это Ой!

lexa - 19/Июл/2011 23:46

Эге, с точки зрения чтения я на это место не смотрел.

Получается что надо не 1 файл в N копировать, а K в K, так быстрее сдохнет!

kranov (not verified) - 19/Июл/2011 16:40

>В виндоус граждане тоже жалуются на что-то похожее http://ctpeko3a.livejournal.com/506520.html
в виндоусе они недавно копирование так заимпрувили
http://blogs.technet.com/b/markrussinovich/archive/2008/02/04/2826167.aspx

lpauzner (not verified) - 19/Июл/2011 17:23

О!

Inside Vista SP1 File Copy Improvements
Mark Russinovich 4 Feb 2008

Но там еще с корзиной разные тормоза до сих пор происходят, когда она большая и заполнена под завязку.
http://deadracoon.livejournal.com/105450.html
http://deadracoon.livejournal.com/105936.html

lexa - 19/Июл/2011 17:41

Ну у меня затыкается семерка x64 (со всеми понтами).

Редко и не до конца, но все одно неприятно.

dil (not verified) - 18/Июл/2011 14:18

виртуализатор какой?

lexa - 18/Июл/2011 14:26

Vmware Workstation

iskatel (not verified) - 18/Июл/2011 14:48

мягко говоря, не чемпион по части IO прозводительности.
Но и не аутсайдер.
Скажем так - для performance test платформа выбрана неудачно, но всё же разницу при тюнинге или установке лУчшего ядра , по идее, ты должен увидеть.

lexa - 18/Июл/2011 15:01

Ну прямо скажем, производительность IO данной виртуальной машины заметно выше, чем производительность любого десткопа с одним SATA-HDD. Получите на одном SATA 300 Mb/sec и поговорим.

Но и задачи "сравнивать производительность" у меня не было, я хотел проявить 12309.
Проявил.

dil (not verified) - 18/Июл/2011 15:24

Зато для тестирования затыков в IO как раз хорошо будет :)

msh (not verified) - 18/Июл/2011 16:29

Ну прежде всего, стоит выкинуть vmware и поставить KVM, с всеми virtio, включая baloon

lexa - 18/Июл/2011 16:59

А зачем?

У меня же нету задачи, чтобы не затыкалось. У меня, наоборот, стояла задача убедиться, что затыкается.

iskatel (not verified) - 18/Июл/2011 14:47

виртуализация на чём сделана ?

9 потоков IO... харрошая нагрузка.
Приоритеты для своих cp снизь.
Это кроме того, что это, извините, openSUSE. А теперь поставь SLES11, раз уж хочешь Сусю.

lexa - 18/Июл/2011 15:03

Да, SLES поставил пиратиться.

А хочу я, как уже в соседних каментах написал, не Сусю, а свежий девелоперский userland из вменяемого репозитория.

Виденные мной (правда осенью) энтерпрайз-дистрибутивы были в этом месте несколько убоги.

msh (not verified) - 18/Июл/2011 16:30

Свежий девелоперский userland есть только в Ubuntu

lexa - 18/Июл/2011 16:59

В Suse gcc 4.5, что меня уже более-менее удовлетворяет.

proforg (not verified) - 18/Июл/2011 18:16

и в debian sid

k26photo (not verified) - 18/Июл/2011 18:50

Вот есть fuse-zfs raidz на debian squeeze. Duron 1GHz 1Gb. 4HDD IDE.
Linux memus 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686 GNU/Linux
Масштаб эксперимента в десять раз меньше. Сами поймете почему.

$ dd if=/dev/urandom of=/media/memus/backup/los4/test-12309.dd bs=1024k count=1000
1000+0 записей считано
1000+0 записей написано
скопировано 1048576000 байт (1,0 GB), 1447,56 c, 724 kB/c

В это время

$ zpool iostat 60
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
....
memus 198G 130G 61 660 118K 2,19M
memus 198G 130G 62 119 122K 1,45M
memus 198G 130G 62 105 142K 1,49M

$ vmstat 60
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 1 0 1000256 2328 61396 0 0 227 2377 538 1032 9 5 47 38
1 1 0 1022948 2328 19804 0 0 237 1676 555 1086 7 6 48 39
0 0 0 1019104 2328 22324 0 0 257 2192 552 1073 9 5 46 40
0 0 0 1007316 2344 32476 0 0 217 1780 531 1040 7 5 48 40
0 1 0 981648 2352 57040 0 0 190 2015 539 1059 8 5 46 40

Теперь пускаем скрипт, указаный в начале треда

$ sudo zpool iostat 60
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
memus 200G 128G 37 66 75,6K 700K
memus 200G 128G 21 241 910K 614K
memus 200G 128G 19 262 932K 701K
memus 200G 128G 20 281 991K 777K
memus 200G 128G 40 157 620K 372K
memus 200G 128G 40 159 752K 412K

$ vmstat 60
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 1 0 870164 2716 156176 0 0 138 1065 305 631 4 10 64 22
0 1 0 390416 2744 658836 0 0 952 959 671 1814 45 13 23 18
0 0 0 28300 2160 1021688 0 0 912 1065 697 1916 47 14 21 19
0 1 0 31152 2160 1016008 0 0 1037 1222 819 2184 52 16 20 12
0 0 0 23588 2160 1022832 0 0 681 696 684 1817 33 12 33 23
0 1 0 27076 2184 1018104 0 0 734 616 654 1720 30 11 34 25
9 3 0 27184 2184 1016952 0 0 880 606 661 1753 30 10 34 25

И никаких заклиниваний. Хороший результат для маленького и гордого надежного хранилища фоток, ящетаю.

lexa - 18/Июл/2011 19:03

Даже с поправкой на Duron, я на 700kb/sec пойтить ну никак не могу!

k26photo (not verified) - 18/Июл/2011 19:55

На той же машине, но пул dedup=off, compress=off

$ vmstat 60
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 1 0 352900 584 606456 0 0 235 863 309 683 8 8 64 20
0 0 0 337996 596 606548 0 0 349 1 533 1417 3 4 49 44
1 1 0 221056 604 782684 0 0 686 6545 734 2347 13 12 30 45
10 1 0 27108 300 1005616 0 0 1902 20352 736 2337 25 22 24 29
3 1 0 26496 276 1002544 0 0 1734 23341 743 2395 28 23 22 27
....
10 1 0 24780 440 993856 0 0 1787 22162 766 2430 27 23 24 26
0 0 0 25480 384 994176 0 0 895 9792 391 1169 12 10 64 14
0 0 0 25480 384 994176 0 0 0 0 40 15 0 0 100 0

$ sudo zpool iostat 60
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
memus 200G 128G 32 70 183K 565K
memus 200G 128G 196 0 350K 0
memus 200G 128G 73 596 592K 5,48M
memus 201G 127G 26 253 1,52M 14,2M
memus 202G 126G 27 255 1,69M 14,7M
....
memus 212G 116G 33 250 1,61M 14,1M
memus 213G 115G 10 87 427K 4,59M
memus 213G 115G 0 0 0 0

_slw (not verified) - 19/Июл/2011 15:03

у тебя в стандалон-блоге треды бьются.

lexa - 19/Июл/2011 15:06

Что, ОБА?

У меня в стандалон-блоге ID комментариев уже под 20к.

Может быть ты покажешь поточнее?

_slw (not verified) - 19/Июл/2011 15:10

не знаю что ты имеешь ввиду, может ТРОЕ.

ну глянь в предыдущих двух постах как треды нарисованы и кому на самом деле ответ предназначался.

вероятно при импорте ветки из жж при наличии камента в блоге второй и последующий каменты жжшной ветки цепляются не к жжшному каменту, а к каменту в блоге.

lexa - 19/Июл/2011 15:45

Предыдущий посмотрел - проблемы не увидел.

_slw (not verified) - 19/Июл/2011 15:51

видимо предпредыдущий был настолько обширным, что создал впечетление что смотрю два. в предпредыдущем точно есть.

lexa - 19/Июл/2011 16:14

И там не вижу. Дай точную ссылку (хинт - у заголовка каждого коммента есть собственный URL c #comment-ID).

Там вот есть, что если в стандалоне отвечали на ЖЖ-шный камент, то образуется своя ветка (которой нет в ЖЖ), которая может быть выше ЖЖ-шного продолжения. Но я не вижу в этом проблемы.

_slw (not verified) - 19/Июл/2011 16:20

И там не вижу. Дай точную ссылку (хинт - у заголовка каждого коммента есть собственный URL c #comment-ID).
http://blog.lexa.ru/2011/07/17/linux_vs_freebsd.html#comment-18683

b00ter отвечал на самом деле мне, а получилось -- кике, сравни с жж.

это не единственный случай.

Там вот есть, что если в стандалоне отвечали на ЖЖ-шный камент, то образуется своя ветка (которой нет в ЖЖ), которая может быть выше ЖЖ-шного продолжения. Но я не вижу в этом проблемы.
я болею, потому не понял о чем ты. но, вероятно это и не важно.

lexa - 19/Июл/2011 16:31

Во, теперь увидел! Спасибо!

Хотя разбираться сейчас не буду, жарко, моск пухнет. Но пометку сделал.

Anonymous (not verified) - 19/Июл/2011 22:38

Writeback на RAID-массиве включен?

k26photo (not verified) - 21/Июл/2011 06:00

zfs get all mypool | grep writeback
ничего не показал. Где посмотреть?

rezdm (not verified) - 19/Июл/2011 22:55
  • Про копирование в Винде не Виндой. Я периодически, бывает, ну слабость у меня такая, перегоняю «гигазы вареза» ;) с диска на диск. Копирую FileCopyEx. Винда, 7ка, 64. Не затыкалась. В несколько потоков (4-6), всё по-чесному. Каждый Фар в один поток читает, в другой пишет, и таких 4-6 штук.
  • В Висте, да, была гадость какая-то (ссылку на Руссиновича уже дали).
  • Недавно убирал веники, переставлял, т.п., копировал виндой. К сожалению, сснёс скриншот, таки делал специально: в шесть потоков копировал содержимое папок. Содержимое — флаки, то бишь куча файлов, размером 10-50мб, общий объём где-то под 1.5Тб. Нормуль, ничего не встало.
  • Не холивара ради, а корысти для. Лет семь назад я проводил подобный эксперимент, Солярка 2.6 на х86 вс линух (Слакварь какая-то) вс Винда (2к на тот момент). Меня интересовали не абсолютные величины, а скорее подтвердить впечатления, замеченные во время эксплуатации. Также копировал, пробовал выделать кучей процессов кучу памяти. Тест с точки зрения реальной жизни мало о чём говорящий, повторюсь, хотелось впечатление проверить эдаким синтетическим тестом. РЕзультат был такой: линух именно "затыкался" на какое-то время совсем намертво. Винда и Солярка худо-бедно но продолжали шевелиться.0

    lexa - 19/Июл/2011 23:27

    FileCopyEX, как я помню, контролирует свои буфера, а из них уже пишет "мимо кэша".

    Это совсем другой паттерн.

    lexa - 19/Июл/2011 23:49

    Да, кстати, неужто 6 потоков с диска на диск - быстрее чем один?

    rezdm (not verified) - 19/Июл/2011 23:52

    Ждать завершения, чтобы начать копирование следующего, лень, вот я и вжарил все сразу.