Re: Тормоза nbackup

2011-01-13 Thread Roman Simakov 
12 января 2011 г. 23:05 пользователь Viktor Belzetskiy
 написал:
>>> 2. Запускаем nbackup 0-го уровня (nbackup еле шевелится по диску
>>> {10мб/с} при практически 100% загрузке проца)
>>
>> Какой процесс грузит процессор ?
>
> Речь именно о nbackup, он и грузит.
>
>> ALTER DATABASE BEGIN BACKUP
>> Бекап 0-го уровня - тупое копирование файла БД.
>> ALTER DATABASE END BACKUP
>
>> С блокировками, слиянием дельты в БД и прочим работает движок, а не
>> nbackup.
>
> Я это прекрасно понимаю потому и возник вопрос.

Гипотез к сожалению пока нет, но я бы еще поэкспериментировал так.

Может попробовать вместо nbackup руками воспроизвести тоже самое?
Т.е. в твоей последовательности пункт 2) развернуть на:
2a. Запускаем в isql alter database begin backup
2b. Когда завершиться 2a, копирование файла на тот же диск где дельта
(можно еще поиграть с расположением после)
потом тоже самое и понаблюдать за процессом копирования вместо nbackup.

Еще было интересно, а если 2) и 1) поменять местами, nbackup
притормозит после начала удаления.

--
Роман Симаков

Re: Странные обрывы соединения

2011-01-13 Thread Konstantin R. Beliaev 

Oleg Matveyev wrote:

KeepAliveTime = 12
KeepAliveInterval = 1000
MaxDataRetries - нету такого
TcpMaxDataRetransmissions = 10


подитожим.
на сервере, где стоит FB & FBScanner, и _так_ настроен Keep Alive,

через 125 секунд после выдергивания сетевого шнура у клиента
- никакой реакции в firebird.log и FBScanner.log ?


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

Или я ошибаюсь, и восстанавливается именно предыдущее соединение?

Re: Странные обрывы соединения

2011-01-13 Thread Oleg Matveyev 
125 секунд я не ждал, я жал кнопу в программе - на сервер уходил запрос, 
который обламывался и сообщал мне об обрыве связи.
В ФИБах включена опция восстановления связи при обрыве - после втыкания 
шнура она срабатывает и восстанавливает соединение. Но насколько я 
понимаю, это - уже другое соединение с другим процессом классика, разве 
нет? А предыдущее должно спокойно умереть с отметками в логах.

Или я ошибаюсь, и восстанавливается именно предыдущее соединение?


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


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

Сам проверял.

   Если же при вытащенном шнуре клиент попробует обратиться к серверу FB, 
то обрыв заметит fbclient.dll, выйдет ошибка "Enable to complete network 
request to host " ... и после уже fib-ы будут создавать новое соединение.



   Далее. Сервер вытаскивания пачкорда из клиентской машины не заметит до 
тех пор, пока не попробует что-то отправить клиенту (например. dummy 
packet), или пока не сработает keepalive на самом сервере. И только после 
этого закроет этот коннект с записью в firebird.log
   Что при этом было на сервере - FB или FBScanner - неважно. Они оба 
реагируют на закрытие сокета самой ОС.

Re: Тормоза nbackup

2011-01-13 Thread Viktor Belzetskiy 

Повторяю серию тестов на базе меньшего размера и рядом измерений.

Итак:
Тестовый сервер
4-х ядерный Intel I5 3.6ГГц
Intel Matrix (soft) RAID 0 6HDD 2Тb (пиковые линейные (HDTune) 
чтение/запись 700/400 МБ/с) Все кеширование включено

Память 8Г

ПО
Операционка Win2008 R2 x64
FB V2.5.0.26074 CS Win32 (DefaultDbCachePages = 4096)
База 54G (размер страницы 16К)
Мониторинг Iarsn TasckInfo

Описание процесса тестирования.
Систему ничего не загружает кроме указанных задач.
Система и Win SWAP находитмся на отдельном физическом диске.
Все базы и их бекапы на другом RAID-диске
Из базы удаляем 100млн записей и запускаем Nbackup 0-го уровня.
Смотрим загрузку ядра процессом Nbackup.ехе (норминуем значение для 100% 
поскольку система на 4-х ядрах)
Например TasckInfo показывает 25% для процесса Nbackup.ехе - это 
означает что Nbackup.ехе грузит свое ядро на 100%
Нагрузку дисковой подсистемы смотрим тем же TasckInfo но уже для всей 
системы целиком
Перед каждым тестом базу всегда восстанавливаем из backup-а (nbackup.exe 
-u sysdba -p masterkey -R localhost:e:\test_db\retail.fdb 
e:\test_db\retail_0.nbk)
Время выполнения восстановления 4м 40с (нагрузка дисковой подсистемы 
200-300 м/с) что равно файловому копированию.

Размер создаваемого дельтатафла ~9Гб

Удаление данных происходит в отдельном коннекте.

Сначала запускается шаг1, после паузы в 5 секунд шаг 2.

Тест1
1. nbackup.exe -u sysdba -p masterkey -D OFF -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk

2. Удаление данных


Результат1
Загрузка процесса Nbackup 8-12%
Дисковый I/O во время создания копии 100-200мб/с
Загрузка FB-процесса удаления данных 40-60%.
Дисковый I/O во время сброса дельтафайла 30-40мб/с
Время работы Nbackup до момента сброса дельтафайла (запуска FB процесса) 
7m 20s

Время сброса дельтафайла 5m 07s
Время удаления данных 11m 14s
ВНИМАНИЕ: Синхронное завершение процесса сброса дельтафайла и процесса 
удаления данных.


Тест2
1. Удаление данных
2. Запуск nbackup.exe -u sysdba -p masterkey -D OFF -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk



Результат2 приблизительно аналогичный Результат1


Тест3 (без ключа -D OFF)
1. Удаление данных
2. nbackup.exe -u sysdba -p masterkey -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk
3а. После ожидания 22 минут закрываем коннект в котором происходило 
удаление данных



Результат3
Загрузка процесса Nbackup: начало 60% - конец ~100%
Загрузка FB-процесса удаления данных: начало 15% конец 8%.
Дисковый I/O во время создания бекапа: начало 100мб/с конец 10мб/с
Рост нагрузки на проц и падение I/O линейное на протяжении всего этапа


... Данные удалились с коммитом. Коннект не закрываем. Время удаления 
данных 15m 13s.
... Прошло 22 минуты с момента старта теста, т.е. 7 мин после завершения 
удаления данных бекап прошел на 60%.

Загрузка процесса Nbackup 100%
Дисковый I/O 9м/с

... Надоело !!! Закрываем коннект в котором происходило удаление данных
Дисковый I/O 200-300мб/с
Загрузка процесса Nbackup 20%
Время работы Nbackup до момента сброса дельтафайла (запуска FB процесса) 
27m 37s (т.е. за 5 мин прошло остальных 40% бекапа)


... Сброс дельтафайла
Время сброса дельтафа

Re: Тормоза nbackup

2011-01-13 Thread Viktor Belzetskiy 

Повторяю серию тестов на базе меньшего размера и рядом измерений.

Итак:
Тестовый сервер
4-х ядерный Intel I5 3.6ГГц
Intel Matrix (soft) RAID 0 6HDD 2Тb (пиковые линейные (HDTune) 
чтение/запись 700/400 МБ/с) Все кеширование включено

Память 8Г

ПО
Операционка Win2008 R2 x64
FB V2.5.0.26074 CS Win32 (DefaultDbCachePages = 4096)
База 54G (размер страницы 16К)
Мониторинг Iarsn TasckInfo

Описание процесса тестирования.
Систему ничего не загружает кроме указанных задач.
Система и Win SWAP находитмся на отдельном физическом диске.
Все базы и их бекапы на другом RAID-диске
Из базы удаляем 100млн записей и запускаем Nbackup 0-го уровня.
Смотрим загрузку ядра процессом Nbackup.ехе (норминуем значение для 100% 
поскольку система на 4-х ядрах)
Например TasckInfo показывает 25% для процесса Nbackup.ехе - это 
означает что Nbackup.ехе грузит свое ядро на 100%
Нагрузку дисковой подсистемы смотрим тем же TasckInfo но уже для всей 
системы целиком
Перед каждым тестом базу всегда восстанавливаем из backup-а (nbackup.exe 
-u sysdba -p masterkey -R localhost:e:\test_db\retail.fdb 
e:\test_db\retail_0.nbk)
Время выполнения восстановления 4м 40с (нагрузка дисковой подсистемы 
200-300 м/с) что равно файловому копированию.

Размер создаваемого дельтатафла ~9Гб

Удаление данных происходит в отдельном коннекте.

Сначала запускается шаг1, после паузы в 5 секунд шаг 2.

Тест1
1. nbackup.exe -u sysdba -p masterkey -D OFF -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk

2. Удаление данных


Результат1
Загрузка процесса Nbackup 8-12%
Дисковый I/O во время создания копии 100-200мб/с
Загрузка FB-процесса удаления данных 40-60%.
Дисковый I/O во время сброса дельтафайла 30-40мб/с
Время работы Nbackup до момента сброса дельтафайла (запуска FB процесса) 
7m 20s

Время сброса дельтафайла 5m 07s
Время удаления данных 11m 14s
ВНИМАНИЕ: Синхронное завершение процесса сброса дельтафайла и процесса 
удаления данных.


Тест2
1. Удаление данных
2. Запуск nbackup.exe -u sysdba -p masterkey -D OFF -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk



Результат2 приблизительно аналогичный Результат1


Тест3 (без ключа -D OFF)
1. Удаление данных
2. nbackup.exe -u sysdba -p masterkey -B 0 
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk
3а. После ожидания 22 минут закрываем коннект в котором происходило 
удаление данных



Результат3
Загрузка процесса Nbackup: начало 60% - конец ~100%
Загрузка FB-процесса удаления данных: начало 15% конец 8%.
Дисковый I/O во время создания бекапа: начало 100мб/с конец 10мб/с
Рост нагрузки на проц и падение I/O линейное на протяжении всего этапа


... Данные удалились с коммитом. Коннект не закрываем. Время удаления 
данных 15m 13s.
... Прошло 22 минуты с момента старта теста, т.е. 7 мин после завершения 
удаления данных бекап прошел на 60%.

Загрузка процесса Nbackup 100%
Дисковый I/O 9м/с

... Надоело !!! Закрываем коннект в котором происходило удаление данных
Дисковый I/O 200-300мб/с
Загрузка процесса Nbackup 20%
Время работы Nbackup до момента сброса дельтафайла (запуска FB процесса) 
27m 37s (т.е. за 5 мин прошло остальных 40% бекапа)


... Сброс дельтафайла
Время сброса дельтафа

Re: Странные обрывы соединения

2011-01-13 Thread Konstantin R. Beliaev 

Oleg Matveyev wrote:
   Если же при вытащенном шнуре клиент попробует обратиться к серверу 
FB, то обрыв заметит fbclient.dll, выйдет ошибка "Enable to complete 
network request to host " ... и после уже fib-ы будут создавать новое 
соединение.



   Далее. Сервер вытаскивания пачкорда из клиентской машины не заметит 
до тех пор, пока не попробует что-то отправить клиенту (например. dummy 
packet), или пока не сработает keepalive на самом сервере. И только 
после этого закроет этот коннект с записью в firebird.log
   Что при этом было на сервере - FB или FBScanner - неважно. Они оба 
реагируют на закрытие сокета самой ОС.





Ну, так это самое и происходит: "Enable to complete network request...", 
потом переподключение. На сервере появляется второй процесс.
Через несколько минут птица обнаруживает потерю коннекта и гасит первый 
процесс.
У меня два сервера. На одном появляется запись в FBScanner.log, на 
другом - нет :((

Правда, "другой" - это тот, где слетела регистрация FBScanner.
В логах птицы нет записей ни там, ни там.

Re: Странные обрывы соединения

2011-01-13 Thread Oleg Matveyev 
У меня два сервера. На одном появляется запись в FBScanner.log, на 
другом - нет :((

Правда, "другой" - это тот, где слетела регистрация FBScanner.
В логах птицы нет записей ни там, ни там.


без ключа он не работает :-)
тупо TCP-туннель пробрасывает и все, чтобы коннект работал.
пишет ли при этом лог - непомню, скорее нет.

P.S. я ж тебе отправил ключ

Re: Тормоза nbackup

2011-01-13 Thread Dmitry Yemanov 

13.01.2011 14:39, Viktor Belzetskiy пишет:


Повторяю серию тестов на базе меньшего размера и рядом измерений.


На меньшем размере не так интересно, файловый кеш будет по-другому влиять.


Тест1
1. nbackup.exe -u sysdba -p masterkey -D OFF -B 0
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk
2. Удаление данных

Тест2
1. Удаление данных
2. Запуск nbackup.exe -u sysdba -p masterkey -D OFF -B 0
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk


Оба процесса (фб и нбекап) читают базу через файловый кеш. Получается 
это у них неплохо вроде бы.



Тест3 (без ключа -D OFF)
1. Удаление данных
2. nbackup.exe -u sysdba -p masterkey -B 0
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk

Тест4
1. nbackup.exe -u sysdba -p masterkey -D ON -B 0
localhost:e:\test_db\retail.fdb e:\test_db\retail_0_1.nbk
2. Удаление данных


Эти два варианта делают одно и тоже, на винде у нбекапа режим direct_io 
по дефолту ON. НБекап читает файл БД напрямую с диска, фб-сервер - через 
кеш.


Иногда это работает быстрее, иногда наоборот. Зависит от версии виндов и 
размера базы. Кроме того, приоритеты у всех разные - кому-то надо 
быстрее бекап выполнить, а кому-то - чтобы он не сильно мешал работать. 
Поэтому и сделали этот ключ доступным.



--
Дмитрий Еманов

Re: Тормоза nbackup

2011-01-13 Thread Vlad Khorsun 

"Viktor Belzetskiy" ...

Повторяю серию тестов на базе меньшего размера и рядом измерений.

Итак:
Тестовый сервер
4-х ядерный Intel I5 3.6ГГц
Intel Matrix (soft) RAID 0 6HDD 2Тb (пиковые линейные (HDTune)


   Это не совсем soft RAID, насколько я понимаю. Он всё же поддерживается 
чипсетом,
но в какой степени - не вникал. В любом случае - это не то железо, на котором 
имеет
смысл работать предприятию. Разработчику и\или тестеру - возможно, но не в бой.

...

Тест3 (без ключа -D OFF)
1. Удаление данных
2. nbackup.exe -u sysdba -p masterkey -B 0 localhost:e:\test_db\retail.fdb 
e:\test_db\retail_0_1.nbk
3а. После ожидания 22 минут закрываем коннект в котором происходило удаление 
данных


Результат3
Загрузка процесса Nbackup: начало 60% - конец ~100%
Загрузка FB-процесса удаления данных: начало 15% конец 8%.
Дисковый I/O во время создания бекапа: начало 100мб/с конец 10мб/с
Рост нагрузки на проц и падение I/O линейное на протяжении всего этапа


... Данные удалились с коммитом. Коннект не закрываем. Время удаления данных 
15m 13s.
... Прошло 22 минуты с момента старта теста, т.е. 7 мин после завершения 
удаления данных бекап прошел на 60%.
Загрузка процесса Nbackup 100%


   Расклад user\kernel не смотрел ?



Тест5
1. nbackup.exe -u sysdba -p masterkey -L localhost:e:\test_db\retail.fdb
2. Удаление данных
3. Копировани базы на тот-же диск с помощью FAR


   А если взять xcopy, а не FAR ?

--
Хорсун Влад