ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
20 сообщений из 45, страница 2 из 2
  2  все
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38523924
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.
я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моменты

ТаблоидКак видно по логам, при затыках
1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?)
26261 - коннект с инсертами, 26263 - кешрайтер

ТаблоидДля информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче.
два раза из трех кешрайтер пишет на диск
...
Рейтинг: 0 / 0
13.01.2014, 10:28:33
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524281
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моментыДа, ты прав; впрочем, значения % времени, пока проц ждал завершения IO, невелики: всего 7%.
Лог isql:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
08:41:56: gdetl=004050000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=10053 at 08:40:16
08:41:57: gdetl=004060000  min_ms=476 at 08:36:12  cur_ms=723  max_ms=10053 at 08:40:16
08:41:58: gdetl=004070000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=10053 at 08:40:16
08:41:59: gdetl=004080000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:41:59: gdetl=004090000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:42:00: gdetl=004100000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=10053 at 08:40:16
08:42:12: gdetl=004110000  min_ms=476 at 08:36:12   cur_ms=12216   max_ms=12216 at 08:42:12
08:42:13: gdetl=004120000  min_ms=476 at 08:36:12  cur_ms=739  max_ms=12216 at 08:42:12
08:42:14: gdetl=004130000  min_ms=476 at 08:36:12  cur_ms=732  max_ms=12216 at 08:42:12
08:42:14: gdetl=004140000  min_ms=476 at 08:36:12  cur_ms=722  max_ms=12216 at 08:42:12
08:42:15: gdetl=004150000  min_ms=476 at 08:36:12  cur_ms=723  max_ms=12216 at 08:42:12
08:42:16: gdetl=004160000  min_ms=476 at 08:36:12  cur_ms=724  max_ms=12216 at 08:42:12
И соотв-щий лог vmstat'a:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
08:41:56 2014: procs -----------memory---------- ---swap--      -----io---- --system-- -----cpu------ ---timestamp---
08:41:56 2014:  r  b   swpd   free   buff  cache      si   so    bi     bo    in    cs us sy id  wa  st
08:41:56 2014:  2  0 108252 22336912  61900 9352260    0    0     0      0 10811 19205  6  3 91  0  0	2014-01-13 08:41:56 MSK
08:41:57 2014:  1  0 108252 22332820  61900 9355972    0    0     0      0 10718 19097  6  3 91  0  0	2014-01-13 08:41:57 MSK
08:41:58 2014:  1  0 108252 22329348  61900 9359436    0    0     0      0 10822 19151  6  3 91  0  0	2014-01-13 08:41:58 MSK
08:41:59 2014:  1  0 108252 22325628  61908 9362964    0    0     0     20 10896 19385  7  3 91  0  0	2014-01-13 08:41:59 MSK
08:42:00 2014:  1  0 108252 22321784  61908 9366976    0    0     0      0 10889 19346  6  3 91  0  0	2014-01-13 08:42:00 MSK
08:42:01 2014:  0  1 108252 22321164  61908 9366980    0    0     0 137244 23363  1523  0  1 93   6   0	2014-01-13 08:42:01 MSK
08:42:02 2014:  0  1 108252 22321048  61908 9366980    0    0     0  29888  5222   460  0  0 92   7   0	2014-01-13 08:42:02 MSK
08:42:03 2014:  0  1 108252 22321048  61908 9366988    0    0     0  31244  5543   488  0  0 92   7   0	2014-01-13 08:42:03 MSK
08:42:04 2014:  0  1 108252 22321048  61916 9366980    0    0     0  31652  5577   500  0  0 92   7   0	2014-01-13 08:42:04 MSK
08:42:05 2014:  0  1 108252 22321048  61916 9366988    0    0     0  32944  5764   523  0  0 92   7   0	2014-01-13 08:42:05 MSK
08:42:06 2014:  0  1 108252 22320908  61916 9367084    0    0     0  29716  5327   481  0  0 92   7   0	2014-01-13 08:42:06 MSK
08:42:07 2014:  1  1 108252 22320908  61916 9367084    0    0     0  29892  5380   475  0  0 92   7   0	2014-01-13 08:42:07 MSK
08:42:08 2014:  0  1 108252 22320536  61916 9367088    0    0     0  79812  2581   290  0  0 92   8   0	2014-01-13 08:42:08 MSK
08:42:09 2014:  0  2 108252 22320668  61916 9367088    0    0     0  20632  3908   476  0  0 92   7   0	2014-01-13 08:42:09 MSK
08:42:10 2014:  0  2 108252 22320668  61916 9367088    0    0     0  28632  5376   573  0  0 92   8   0	2014-01-13 08:42:10 MSK
08:42:11 2014:  0  2 108252 22320668  61916 9367088    0    0     0  29624  5396   483  0  0 92   7   0	2014-01-13 08:42:11 MSK
08:42:12 2014:  1  0 108252 22318808  61932 9369260    0    0     0  14696  7361  8371  3  2 91   4   0	2014-01-13 08:42:12 MSK
08:42:13 2014:  1  0 108252 22315088  61932 9372760    0    0     0      8  9902 17417  7  3 90  0  0	2014-01-13 08:42:13 MSK
08:42:14 2014:  1  0 108252 22311616  61940 9376040    0    0     0     28  9540 16655  6  3 90  0  0	2014-01-13 08:42:14 MSK
08:42:15 2014:  1  0 108252 22307772  61940 9380060    0    0     0      4 10026 17724  6  3 91  0  0	2014-01-13 08:42:15 MSK
08:42:16 2014:  1  0 108252 22304300  61940 9383900    0    0     0      0  9941 17693  7  3 91  0  0	2014-01-13 08:42:16 MSK
08:42:17 2014: procs -----------memory---------- ---swap--     -----io---- --system-- -----cpu------ ---timestamp---
08:42:17 2014:  r  b  swpd      free   buff   cache   si   so    bi    bo   in   cs    us sy id wa st
08:42:17 2014:  4  0 108252 22300456  61940 9387740    0    0     0     0 10392 18438  7  3  91  0  0	2014-01-13 08:42:17 MSK
08:42:18 2014:  1  0 108252 22296860  61940 9391324    0    0     0    16 10474 18442  7  3  91  0  0	2014-01-13 08:42:18 MSK
dimitrТаблоидКак видно по логам, при затыках
1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 26261 - коннект с инсертами , 26263 - кешрайтерТогда это еще сильнее интригует! Почему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ?
...
Рейтинг: 0 / 0
13.01.2014, 13:42:32
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524308
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Дениснафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш).Ну, это так, конечно: согласно принципу careful writes, он должен записывать страницы в строго определённом порядке.
 
Ann Harrison - On disk consistency http://www.ibphoenix.com/resources/documents/design/doc_20 when the system writes a page that references another page, that other page must have been written previously in a state that supports the reference. Before writing a page that has a pointer from a record to its back version on another page, the system must have written that other page. Before writing out a new data page, the system must write out a version of a page information page (PIP) that shows the page is in use. The new data page has to be on disk, formatted and happy, before the table's pointer page that references the new page can be written.

Inter-page relationships are handled in the code through a dependency graph in the cache manager. Before a page is written, the cache manager checks the graph and writes out all pages that page depends on. If a change will create a loop in the graph, the cache manager immediately writes as many pages as necessary to avoid the loop.
Только сутки ждать заполнения базы зело не хочется... %-)
...
Рейтинг: 0 / 0
13.01.2014, 13:55:17
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524310
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисвроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались.Жаль, что это так. Неудобно во многих случаях.

BTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?
...
Рейтинг: 0 / 0
13.01.2014, 13:56:33
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524315
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

тогда жди вот этого

Vladyslav Khorsun2. Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on

This feature is implemented for disk reads and i'm looking what can be done for disk writes too. Testing and some platform dependent adaptation is needed. (The implementation was tested briefly on Windows and Linux.)
...
Рейтинг: 0 / 0
13.01.2014, 13:58:42
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524323
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
ТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?

Начал. Уже Владу отправлял результаты. Пока не совсем однозначно. Где-то выигрываем где то проигрываем. Думаю когда вот это "Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on" сделают преимущество будет значительно заметнее.
...
Рейтинг: 0 / 0
13.01.2014, 14:01:52
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524357
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?Пока не совсем однозначно. Где-то выигрываем где то проигрываем.а меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем).
...
Рейтинг: 0 / 0
13.01.2014, 14:20:44
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524379
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидИ соотв-щий лог vmstat'a:Только я вижу us = 0 в эти моменты ? И сильно не нулевой bo

 
насколько я понимаю
us == CPU\user
bo == blocks out


ТаблоидПочему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ?Опять пальцем в небо. Тебе же dimitr показал, что "страдает" коммит...
...
Рейтинг: 0 / 0
13.01.2014, 14:31:58
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524388
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

я тебе позже отправлю свой тест в личку. Возможно причина в том, что ось Windows 7 по умолчанию не оптимизирована под сервисы, да и дисковая подсистема там обычная, никаких RAIDов нету.
...
Рейтинг: 0 / 0
13.01.2014, 14:38:48
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524397
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоида меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем).

так и должно быть. По идее выигрыш должен быть везде где есть NATURAL скан
...
Рейтинг: 0 / 0
13.01.2014, 14:46:23
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524992
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Вести с полей.

Изменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:
Код: plaintext
1.
2.
3.
4.
5.
grep ext4 /etc/fstab;
#UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19 /                       ext4    defaults        1 1
UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19 /                       ext4     noatime,barrier=0    1 1
UUID=22b8cf00-0227-4e30-8cde-9f985e69bcd4 /boot                   ext4    defaults        1 2
UUID=aadceb5b-668d-4968-80fe-554a8a352ad7 /u01                    ext4    defaults        1 2

Запустил с нуля isql + iotop + vmstat.
Сначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек.
Одинг или два раза, впрочем, был затык на несколько десятков сек (около 20 сек вроде).

Но вот после сотого ляма, кажись, тихо наступает Жо:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
19:58:53: gdetl=106410000  min_ms=483 at 16:47:22  curr_ms=11305  max_ms=231549 at 19:38:13
19:59:04: gdetl=106420000  min_ms=483 at 16:47:22  curr_ms=11438  max_ms=231549 at 19:38:13
19:59:26: gdetl=106430000  min_ms=483 at 16:47:22  curr_ms=21527  max_ms=231549 at 19:38:13
20:00:03: gdetl=106440000  min_ms=483 at 16:47:22  curr_ms=37192  max_ms=231549 at 19:38:13
20:02:14: gdetl=106450000  min_ms=483 at 16:47:22  curr_ms=130718  max_ms=231549 at 19:38:13
20:02:18: gdetl=106460000  min_ms=483 at 16:47:22  curr_ms=4733  max_ms=231549 at 19:38:13
20:02:21: gdetl=106470000  min_ms=483 at 16:47:22  curr_ms=2695  max_ms=231549 at 19:38:13
20:02:24: gdetl=106480000  min_ms=483 at 16:47:22  curr_ms=2784  max_ms=231549 at 19:38:13
20:02:27: gdetl=106490000  min_ms=483 at 16:47:22  curr_ms=2702  max_ms=231549 at 19:38:13
20:02:29: gdetl=106500000  min_ms=483 at 16:47:22  curr_ms=2523  max_ms=231549 at 19:38:13
20:02:32: gdetl=106510000  min_ms=483 at 16:47:22  curr_ms=2627  max_ms=231549 at 19:38:13
20:02:34: gdetl=106520000  min_ms=483 at 16:47:22  curr_ms=2594  max_ms=231549 at 19:38:13
20:02:37: gdetl=106530000  min_ms=483 at 16:47:22  curr_ms=2514  max_ms=231549 at 19:38:13
20:02:39: gdetl=106540000  min_ms=483 at 16:47:22  curr_ms=2407  max_ms=231549 at 19:38:13
20:02:59: gdetl=106550000  min_ms=483 at 16:47:22  curr_ms=19704  max_ms=231549 at 19:38:13
20:04:02: gdetl=106560000  min_ms=483 at 16:47:22  curr_ms=63092  max_ms=231549 at 19:38:13

Однако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWrites (что должны БЫЛО БЫ сбрасывать в кеш операционки фиксированные объёмы строк).
Я дождусь его окончания, конечно, дабы затолкать в свой "лог успехов и поражений". После чего попробую с автономками (скрипт см выше).

Если и там всё упрётся, то последнюю и опасную меру, буду добавлять в /etc/fstab атрибут выключения журнала ext4: data=writeback.
...
Рейтинг: 0 / 0
13.01.2014, 20:11:50
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38524998
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
И еще одна мысль вслух: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt Write barriers enforce proper on-disk ordering
of journal commits , making volatile disk write caches
safe to use, at some performance penalty. If
your disks are battery-backed in one way or another,
disabling barriers may safely improve performance.Есть смутное ощущение, что поскольку ФБ сам выдаёт нужный порядок записи страниц (careful writes), при любом FW, то эти барьеры вообще нахрен не нужны, когда на хосте трудится только ФБ (а в бол-ве случаев именно так и происходит). И уж тем более при FW = OFF: раз мы сказали, что можем не ждать, когда ось запишет данные на ДИСК, то тем более по барабану, в какой последовательности она будет их туда записывать.
...
Рейтинг: 0 / 0
13.01.2014, 20:21:23
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525005
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидпо барабану, в какой последовательности она будет их туда записывать.
Не совсем. Уже давным-давно на эти грабли нарывались все СУБД на NTFS: если уронить комп
во время расширения файла, то в каталоге будет записан его новый размер, а новые страницы
останутся пустыми (или наоборот: NTFS журнал откатывал расширение файла, оставляя ссылки
на несуществующие страницы, уже не помню).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
13.01.2014, 20:33:58
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525033
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

про барьеры я уже говорил
http://www.sql.ru/forum/964856/linux-opciya-barrier-i-firebird
и вот
http://www.sql.ru/forum/895986/ext4-barrier-0-ili-1
со слов людей может быть до 3 раз хуже.
...
Рейтинг: 0 / 0
13.01.2014, 21:33:31
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525039
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
возвращаясь к старым гипотетическим баранам:

ТаблоидСначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек.пишем в кеш оси

ТаблоидНо вот после сотого ляма, кажись, тихо наступает Жоось начинает сливать свой кеш на диск

ТаблоидОднако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWritesт.е. никаких принудительных сбросов кеша не было до тех пор, пока он не забился

ЗЫ. напомнило копирование фильма на флешку под линухом - первые 4 гига пишем мегашустро, потом с черепашьей скоростью дописываем остатки, потом еще 10 минут отключаем устройство :-)
...
Рейтинг: 0 / 0
13.01.2014, 21:43:43
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525052
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Интересно будет на idx_under_load базе проверить произв-сть DML, с и без барьеров. Там нет таких сумасшедших объёмов, всё наоборот как раз. Но зато коннектов будет штук 300.
...
Рейтинг: 0 / 0
13.01.2014, 22:10:31
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525093
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ?
...
Рейтинг: 0 / 0
14.01.2014, 00:22:03
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525124
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано.

В итоге, сейчас:
Код: plaintext
1.
2.
3.
4.
[root@oel64 01:49:47 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             243G  144G   88G  63%  / 
tmpfs                  16G     0   16G   0% /dev/shm
. . .


Код: plaintext
1.
[root@oel64 01:49:55 ~]$ grep barrier /etc/fstab
UUID=2f765571-eba5-47f7-96cb-82d85e8f9a19  /  ext4     noatime,barrier=0    1 1

Код: plaintext
1.
[root@oel64 01:50:17 ~]$ mount | grep barrier
/dev/sda4 on  /  type ext4 (rw, noatime,barrier=0 )

И для верности глянул сюда:
Код: plaintext
1.
2.
3.
4.
5.
$ grep -i barrier /var/log/messages
Jan 13 16:39:32 oel64 kernel: dracut: Remounting /dev/disk/by-uuid/2f765571-eba5-47f7-96cb-82d85e8f9a19 with -o noatime,barrier=0,ro
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): barriers disabled
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: barrier=0
Jan 13 16:39:32 oel64 kernel: EXT4-fs (sda4): re-mounted. Opts: barrier=0

Вроде бы всё ОК ?

ЗЫ. Скрипт всё равно в итоге стал ползти как черепаха. Сейчас только 171 млн сделано. Быстрее, конечно, чем в прошлый раз (начал его в 16:47), но всё равно не айс так долго ждать
...
Рейтинг: 0 / 0
14.01.2014, 01:57:47
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525138
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидhvladНа всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано.Ну, можно и рестартануть, если просто перемонтировать не получается :)
...
Рейтинг: 0 / 0
14.01.2014, 03:02:09
| Ответить | Цитировать | Написать  
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
    #38525229
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
"Досчиталось" наконец. Но скрипело под занавес сильно:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
05:35:32: gdetl=199740000  min_ms=483 at 16:47:22  curr_ms=29180  max_ms=282271 at 22:40:34
05:36:28: gdetl=199750000  min_ms=483 at 16:47:22  curr_ms=55692  max_ms=282271 at 22:40:34
05:37:08: gdetl=199760000  min_ms=483 at 16:47:22  curr_ms=40686  max_ms=282271 at 22:40:34
05:37:48: gdetl=199770000  min_ms=483 at 16:47:22  curr_ms=40080  max_ms=282271 at 22:40:34
05:38:38: gdetl=199780000  min_ms=483 at 16:47:22  curr_ms=49879  max_ms=282271 at 22:40:34
05:39:19: gdetl=199790000  min_ms=483 at 16:47:22  curr_ms=40548  max_ms=282271 at 22:40:34
05:39:49: gdetl=199800000  min_ms=483 at 16:47:22  curr_ms=29969  max_ms=282271 at 22:40:34
05:39:50: gdetl=199810000  min_ms=483 at 16:47:22  curr_ms=992  max_ms=282271 at 22:40:34
05:39:51: gdetl=199820000  min_ms=483 at 16:47:22  curr_ms=959  max_ms=282271 at 22:40:34
05:39:52: gdetl=199830000  min_ms=483 at 16:47:22  curr_ms=927  max_ms=282271 at 22:40:34
05:39:54: gdetl=199840000  min_ms=483 at 16:47:22  curr_ms=2645  max_ms=282271 at 22:40:34
05:39:55: gdetl=199850000  min_ms=483 at 16:47:22  curr_ms=969  max_ms=282271 at 22:40:34
05:39:56: gdetl=199860000  min_ms=483 at 16:47:22  curr_ms=977  max_ms=282271 at 22:40:34
05:39:57: gdetl=199870000  min_ms=483 at 16:47:22  curr_ms=984  max_ms=282271 at 22:40:34
05:39:58: gdetl=199880000  min_ms=483 at 16:47:22  curr_ms=945  max_ms=282271 at 22:40:34
05:39:59: gdetl=199890000  min_ms=483 at 16:47:22  curr_ms=900  max_ms=282271 at 22:40:34
05:40:00: gdetl=199900000  min_ms=483 at 16:47:22  curr_ms=945  max_ms=282271 at 22:40:34
05:40:01: gdetl=199910000  min_ms=483 at 16:47:22  curr_ms=1003  max_ms=282271 at 22:40:34
05:40:02: gdetl=199920000  min_ms=483 at 16:47:22  curr_ms=926  max_ms=282271 at 22:40:34
05:40:03: gdetl=199930000  min_ms=483 at 16:47:22  curr_ms=974  max_ms=282271 at 22:40:34
05:40:04: gdetl=199940000  min_ms=483 at 16:47:22  curr_ms=1015  max_ms=282271 at 22:40:34
05:40:05: gdetl=199950000  min_ms=483 at 16:47:22  curr_ms=953  max_ms=282271 at 22:40:34
05:40:06: gdetl=199960000  min_ms=483 at 16:47:22  curr_ms=968  max_ms=282271 at 22:40:34
05:40:35: gdetl=199970000  min_ms=483 at 16:47:22  curr_ms=28910  max_ms=282271 at 22:40:34
05:41:31: gdetl=199980000  min_ms=483 at 16:47:22  curr_ms=55973  max_ms=282271 at 22:40:34
05:42:17: gdetl=199990000  min_ms=483 at 16:47:22  curr_ms=46764  max_ms=282271 at 22:40:34
05:42:39: gdetl=200000000  min_ms=483 at 16:47:22  curr_ms=21318  max_ms=282271 at 22:40:34

Так что буду таки пробовать с data=writeback.
...
Рейтинг: 0 / 0
14.01.2014, 09:48:27
| Ответить | Цитировать | Написать  
20 сообщений из 45, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38525033&tid=1563982]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 230ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 61ms
get tp. blocked users:
 1ms
others: 238ms
total:  568ms
созд. / загр.: 568ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]