Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 Анализ статистики лога бэкапа/рестора  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1341
В FB 3.0 появилась возможность указывать дельту, количество чтений и записей страниц при B/R.
Кто-то уже писал парсер логов, который показывает общую сумму времени по каждой таблице?
Например:
gbak:  0.000      3      0     writing index IBE$LOG_BLOB_FIELDS_IDX1
gbak: 0.080 899 0 writing data for table IBE$LOG_BLOB_FIELDS
gbak: 7.110 3411 0 10000 records written
gbak: 7.423 3279 0 20000 records written
gbak: 5.583 2992 0 30000 records written
gbak: 5.611 3761 0 40000 records written
gbak: 7.772 4087 0 50000 records written
gbak: 7.520 3984 0 60000 records written
gbak: 5.845 3842 0 70000 records written
gbak: 9.625 3866 0 80000 records written
gbak: 6.357 3755 0 90000 records written
gbak: 8.683 3770 0 100000 records written
...
gbak: 18.281 2529 0 10050000 records written
gbak: 16.733 2537 0 10060000 records written
gbak: 6.778 1717 0 10066510 records written

Надо превратить в
IBE$LOG_BLOB_FIELDS: 14956,653 (4,15 ч)

2 hvlad, dimitr: бэкап 35 Гб базы сейчас делается 10 часов, из которых 4 часа - это бэкап одной таблицы IBE$LOG_BLOB_FIELDS, в которой 10 млн строк с блобами. Это нормальное время или что-то в сервере можно ускорить?
13 фев 19, 02:41    [21807938]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27939
CyberMax
35 Гб базы сейчас делается 10 часов

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

ну, если остальное из 35 гиг бэкапится 6 часов, то я предположу крайне хреновый диск.
См.
http://www.ibase.ru/backupspeed3/
Если бэкап идет на другой физ. носитель, то тогда или бэкапный диск медленный шо пипец, или медленный на чтение диск с базой, и тогда с базой всё адски медленно.
13 фев 19, 03:33    [21807949]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
bsv9
Member

Откуда:
Сообщений: 21
База 150 Гб бакапится за 43 минуты. Блобов мало.
13 фев 19, 06:56    [21807967]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1341
FB крутится на виртуалке, и, видимо, сам сервер не сильно шустрый.
Смотрю далее логи и вижу такую картину:
gbak:  0.001      5      9     activating and creating deferred index PK_REG$ABONENT$EQUIPMENT
gbak: 677.862  82093    756     activating and creating deferred index REG$ABONENT$EQUIPMENT_IDX1
gbak:  4.525  82062    547     activating and creating deferred index UNQ1_REG$ABONENT$EQUIPMENT
gbak:  4.777  82069    587     activating and creating deferred index UNQ2_REG$ABONENT$EQUIPMENT
gbak:  5.372  82066   1035     activating and creating deferred index UNQ3_REG$ABONENT$EQUIPMENT
gbak:  5.353  82064   1037     activating and creating deferred index UNQ4_REG$ABONENT$EQUIPMENT
gbak:  5.337  82065    510     activating and creating deferred index LST$PMS$TITLE_DATE_ACCOUNT
gbak: 19.378   2546     64     activating and creating deferred index LST$PMS$TITLE_DATE_LIST

Если я правильно понимаю дельту, то получается, что индекс по ПК таблицы REG$ABONENT$EQUIPMENT строится почти 11 минут, остальные индексы (по текстовым полям) - за 4-5 секунд. Здесь надо увеличивать TempCacheLimit?
Посмотрел по другим индексам. Встречается время создания 1091.973, 3208.326, 1325.738.
P.S. На моем десктопе эта же база ресторится за 2 часа. FB 32-х разрядный, с дефолтной конфигой.
13 фев 19, 08:03    [21807993]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9132
CyberMax
В FB 3.0 появилась возможность указывать дельту, количество чтений и записей страниц при B/R.
Кто-то уже писал парсер логов
Дельты вам не помогут - записи статистики делаются "вначале" и "по круглым датам".
Записей о завершении бэкапа конкретного объекта - просто нет.
Поэтому надо искать строки "по объектам" и считать разницу по абсолютному времени.
Чтение-запись отражает только действия движка, всё, что делает сам gbak туда не попадает.

P.S.
В 2.5.8 статистика тоже есть.
Выберите время и разово сделайте:
  gbak -se localhost:service_mgr -b -g -st t -v -y протокол псевдоним nul-или-/dev/null
Если по данным предпоследней строки будет менее 15МБ/сек - посыпайте голову пеплом.
Если будет менее 25МБ/сек по размеру базы и времени из предпоследней строки - тоже посыпайте.
13 фев 19, 08:15    [21807999]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
CyberMax
Member

Откуда: Хабаровск
Сообщений: 1341
Basil A. Sidorov,

Вы не поняли. Скорость бэкапа и рестора я и так вычислю - по времени создания/закрытия файлов и размеру (она менее 1 мб/сек). Проблема с самой виртуальной машиной конечно есть - недели две назад было все ОК. Суть в том, что я хотел выяснить, на каких именно операциях тормозит сам FB и почему. Возможно, это позволит более правильно настроить конфигу FB или исправить какой-то недостаток в самом коде FB.
13 фев 19, 08:22    [21808002]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9132
CyberMax
Скорость бэкапа и рестора я и так вычислю - по времени создания/закрытия файлов и размеру (она менее 1 мб/сек).
... Суть в том, что я хотел выяснить, на каких именно операциях тормозит сам FB и почему.
Не надо пить боржоми, когда уже отлетели почки.
Решите проблемы дисковой подсистемы гипервизора/vm (безотносительно Firebird), а уже потом начинайте "полировать глюкалу".
Возможно, это позволит более правильно настроить конфигу FB или исправить какой-то недостаток в самом коде FB.
Не позволит. Есть (непубличные) примеры баз, содержащих, в основном, блобы (сотни ГБ).
Скорость бэкапа зависит от используемой инфраструктуры, но не зависит от настроек Firebird.

P.S.
Вы правда думаете, что набившее оскомину "Fast=true" может увеличить скорость работы на полтора порядка (в тридцать раз)?
13 фев 19, 08:33    [21808007]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Basil A. Sidorov
Чтение-запись отражает только действия движка, всё, что делает сам gbak туда не попадает.


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

CyberMax,

не понятно так бекап или рестор? Или и то другое

>> Здесь надо увеличивать TempCacheLimit?

я думаю да, но надо тестировать.
13 фев 19, 09:45    [21808063]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6851
CyberMax
2 hvlad, dimitr: бэкап 35 Гб базы сейчас делается 10 часов, из которых 4 часа - это бэкап одной таблицы IBE$LOG_BLOB_FIELDS, в которой 10 млн строк с блобами. Это нормальное время или что-то в сервере можно ускорить?

бекап через сервисы? Если да, то вряд ли что-то ускоришь.
13 фев 19, 10:45    [21808132]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
hvlad
Member

Откуда:
Сообщений: 10267
CyberMax
Если я правильно понимаю дельту, то получается, что индекс по ПК таблицы REG$ABONENT$EQUIPMENT строится почти 11 минут, остальные индексы (по текстовым полям) - за 4-5 секунд
Заметь, первый индекс стротся долго, остальные - быстро.
Это намекает на кеширование таблицы в памяти, а не на медленную сортировку.
13 фев 19, 11:16    [21808174]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27939
CyberMax
На моем десктопе эта же база ресторится за 2 часа.

ну значит диск на виртуалке просто меденнее в 5 раз, и всё.
13 фев 19, 11:38    [21808218]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47380

CyberMax
Это нормальное время или что-то в сервере можно ускорить?

CORE-4545 могло бы улучшить ситуацию, но ни у кого руки до него не дошли.

Posted via ActualForum NNTP Server 1.5

13 фев 19, 13:24    [21808389]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9468
Dimitry Sibiryakov,

а как сервер должен догадаться будет прочитан один сегмент блоба и он закрыт или он вычитан целиком?
13 фев 19, 13:33    [21808405]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47380

Симонов Денис
а как сервер должен догадаться будет прочитан один сегмент блоба и он закрыт или он
вычитан целиком?

Именно в такой формулировке ему и не надо догадываться: флаг large scan не окажет никакого
влияния на этот случай: в кэше точно так же окажется одна страница.

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

Posted via ActualForum NNTP Server 1.5

13 фев 19, 13:40    [21808411]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
hvlad
Member

Откуда:
Сообщений: 10267
Dimitry Sibiryakov
CyberMax
Это нормальное время или что-то в сервере можно ускорить?

CORE-4545 могло бы улучшить ситуацию, но ни у кого руки до него не дошли.


			// If the blob has more pages than the page buffer cache then mark
			// it as large. If this is a database backup then mark any blob as
			// large as the cumulative effect of scanning many small blobs is
			// equivalent to scanning single large blobs.
13 фев 19, 15:45    [21808619]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47380

Там повыше есть ещё одно условие: наличие множественных подключении. То есть в классике
или, как в случае этого топика, на монопольном тесте, large scan таки не включается.

Posted via ActualForum NNTP Server 1.5

13 фев 19, 16:25    [21808682]     Ответить | Цитировать Сообщить модератору
 Re: Анализ статистики лога бэкапа/рестора  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27939
CyberMax,

ну хорошо, Влад вот пишет, и т.д. И каков же размер кэша ФБ, и размер блобов, которые в этот кэш не влазят? Я имею в виду конкретный сервер и конкретную БД.
13 фев 19, 16:27    [21808687]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить