Вести с полей

Привет всем.

Медленно и печально продираюсь сквозь терни подключения к FB3 минуя fbclient.dll. Добрался до настройки шифрования подключения (op_crypt). Разобравшись что к чему, я даже немного оживился — если делать по уму, то конструкция получается достаточно красивой.
(далее…)

Стрессовое тестирование

Привет всем.

Время от времени нагрузочное тестирование 32-битной сборки IBProvider-a (как правило, отладочной) начинает плющить и оно превращается в стрессовое — не хватает оперативной памяти. Выглядит это вот так:
(далее…)

Подключение к FB через TCP/IP (inet, inet4, inet6)

Привет всем.

Сегодня, созерцая время выполнения тестов новой сборки (21500) c Firebird 2.5 немного опух — через fbclient.dll тесты отрабатывали в 5 раз быстрее чем через встроенный клиент. Подключение к серверу осуществляется через TCP/IP: localhost:d:\database\ibp_test_fb25_d3.gdb.

Результаты для fbclient.dll:

------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED      : 17407
SUCCEEDED     : 17406
FAILED        : 0
WITH WARNINGS : 1 [ 1 warning(s) ]

- - - - - - - - - - - - - - - - - - - - - -
TEST TIMES]
REAL          : 4759506647    [00:07:55.9506647]
USER          : 1640038513    [00:02:44.0038513]
KERNEL        : 299209918     [00:00:29.9209918]
TOTAL         : 1939248431    [00:03:13.9248431]

Результаты для встроенного клиента:

------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED      : 17407
SUCCEEDED     : 17406
FAILED        : 0
WITH WARNINGS : 1 [ 1 warning(s) ]

- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL          : 25232635350   [00:42:03.2635350]
USER          : 1359080712    [00:02:15.9080712]
KERNEL        : 267229713     [00:00:26.7229713]
TOTAL         : 1626310425    [00:02:42.6310425]

Ну, думаю, приплыли. Раньше же такого не было.

После разбора полета обнаружилось, что встроенный клиент сначала пытается подключаться к серверу (FB2.5) через TCP/IPv6, а потом через TCP/IPv4. Из-за IPv6 задержка была такой, что спотыкание процесса выполнения тестов было видно невооруженным взглядом.

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

После явного указания подключения через IPv4 (inet4://localhost/d:\database\ibp_test_fb25_d3.gdb) все нормализовалось.

Результаты перезапуска (на новой тестовой базе данных)

Для fbclient.dll:

------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED      : 17407
SUCCEEDED     : 17405
FAILED        : 0
WITH WARNINGS : 2 [ 2 warning(s) ]

- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL          : 3720155706    [00:06:12.0155706]
USER          : 2020212950    [00:03:22.0212950]
KERNEL        : 382202450     [00:00:38.2202450]
TOTAL         : 2402415400    [00:04:00.2415400]

Для встроенного клиента:

------------------------------------------- [SUMMARY INFORMATION]
[TESTS]
EXECUTED      : 17407
SUCCEEDED     : 17405
FAILED        : 0
WITH WARNINGS : 2 [ 4 warning(s) ]

- - - - - - - - - - - - - - - - - - - - - -
[TEST TIMES]
REAL          : 3601447761    [00:06:00.1447761]
USER          : 1941588446    [00:03:14.1588446]
KERNEL        : 357242290     [00:00:35.7242290]
TOTAL         : 2298830736    [00:03:49.8830736]

Так что, теперь надо будет себя приучать явно указывать версию TCP/IP в строке подключения. Во избежание.

Триал IBProvider v3.31.0 [Сборка 21500]

Привет всем.

Основное изменение в коде OLE DB провайдера

Минимизация случаев, когда провайдер запрашивает тип SQL запроса у сервера (isc_dsql_sql_info, tag: isc_info_sql_stmt_type). Эти данные нужны самому нижнему уровню провайдера для определения «селективных» запросов. Внезапно выяснилось, что InterBase возвращает нулевой идентификатор для запроса «SAVEPOINT …» и это очень сильно удивляет IBProvider:

IBProvider error about unexpected InterBase query

Меня, почему-то, это не очень сильно удивляет.

Сейчас тип запроса «подсказывается» собственным SQL-парсером провайдера.

По идее, это (до кучи) должно сократить время, затрачиваемое на подготовку запросов.

Триал IBProvider v3.31.0 [Сборка 21347]

Привет всем.

Несколько месяцев назад решил поглумиться над клиентом Firebird (v2.5) — заставить его тупить минут 10 над коммитом. Сценарий простой — перед коммитом нужно выполнить 100500 раз execute-close для селективного запроса.

И ничего не получилось. Это меня расстроило и я полез смотреть — какого? Обнаруженное меня тоже расстроило. (далее…)

IBProvider v3.30.2

Привет всем.

Анонсировано новое исправление IBProvider-a.

Забавно, но уже в трех местах нашел идентичную багу — забываю написать return. И это навеяло эпизод из «Особенностей национальной охоты»:

— А я ему говорю, товарищ генерал, берите ниже. Он — бах, и мимо. Бах — мимо. Я уж потом сам стал стрелять.
— Михалыч и мимо?
— А меня это не удивляет. Я, кстати, давно за ним замечаю: не бьет зверя. Не бьет зверя. Стрелять — он стреляет, но так, просто так.

В первом случае (исправлен в 3.30.1) срабатывал ассерт. В релизе проблем не было.

А во втором и третьем (copy&paste) — провайдер неправильно определял код основной ошибки сервера.

 if(!result2.null())
  result2.value(); //нет return

 if(!result1.null())
  result1.value(); //нет return

 //[2015-05-05]
 //статус вектор содержит херню какую-то.

 return ibp_fb_err__unexpected_error;

Вообще, я в таких случаях стараюсь писать так:

 if(!result2.null())
  result2.value(); //нет return

 assert(result2.null());

 if(!result1.null())
  result1.value(); //нет return

 assert(result1.null());

 //[2015-05-05]
 //статус вектор содержит херню какую-то.

 return ibp_fb_err__unexpected_error;

Бага сразу бы вылезла.

Но, похоже, 5 мая 2015 меня явно что-то очень сильно отвлекало 🙂

Вести с полей

Привет всем.

4 июня (2016-го), после того как закончил чертыхаться, перезапустил большое тестирование IBProvider и FB2.5.

Вчера была пройдена критическая точка, в которой произошло зацикливание. Окучено ~660 тысяч тестов.

Сейчас идет фаза «бесконечных» тестов, которые вряд ли доработают до конца — их там около 7 млн, а база уже опухла до 1.3TB (я точно знаю, что это не предел). Текущая статистика базы выглядит так:

Database "d:\database\IBP_TEST_FB25_D3_all.GDB"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              43808420
        Page size               8192
        ODS version             11.2
        Oldest transaction      43643448
        Oldest active           43643449
        Oldest snapshot         43643446
        Next transaction        43643456
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      141439
        Implementation ID       26
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jun 4, 2016 17:13:01
        Attributes

    Variable header data:
        *END*

Сервер наработал 834 часа. Типа 34 календарных дня.

Будем посмотреть, какое событие наступит раньше:
— закончится место на разделе (всего доступно 3.6TB)
— тестовый процесс наработает 1000 часов (пока 549 часов)

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

Хозяйке на заметку

Начал медленно работать ноутбук? Разберите и почистите пыль!

Моему рабочему ноутбуку уже больше 4 лет. Последний раз внутрь него заглядывали больше трех лет назад. В последнее время что-то он стал тупить, хотя вроде есть и 16GB и SSD. Но все никак «руки не доходили» почистить его от пыли.

На прошедших выходных наконец-то этот вопрос был решен.

Первое на что я обратил внимание — ожил индикатор TurboBoost процессора.

А сегодня обнаружил, что сборка плюсовых проектов начала работать в два, В ДВА РАЗА(!), КАРЛ, быстрее.

Это просто праздник какой-то!

Вкратце

1. Вернулся из отпуска
2. Зашел отладчиком в исходный код fbclient.dll v3.0

facepalm

3. Захотелось пожелать разработчикам сервера всего доброго, хорошего настроения и здоровья

Большое тестирование #4

Слева диск «C» и справа диск «C» … И зачем мне два диска «C»?

Сегодня по-раздолбайству в задумчивости убил тестовый процесс, который работал уже седьмую неделю. Нажал не на ту кнопочку 🙂

Да черт с ней, с этой Голландией. Полтора месяца реальной работы — это тоже неплохо.

Тестовая машина та же, что и в прошлый раз — Q6600 / 8GB / выделенный массив 4x1TB WD RE4 в RAID0 на RS2BL040. Обновились только диски в рейде (были RE3).

Сервер: Firebird 2.5.6.26993 (x64, SuperClassic, модифицированный)
Провайдер: 3.29.0.20837 (x64)

Сервер и провайдер откомпилированы в VS2015 Upd2 (полная оптимизация).

Подключение к серверу через TCP/IP (localhost) и собственный клиент провайдера (то есть, без участия fbclient.dll).

Тесты запускались в 4 потока.

(далее…)

« Предыдущие записи