Привет всем.
Может кому интересно.
В прошлое воскресенье я обновил исходники сервера и собрал новую 32-битную
(DEBUG) сборку (и сервера и клиента)
---
Моих изменений (меняющих логику) там было минимум :-)
Только в cvt.cpp (transliterate):
if ((charset1 != charset2) &&
(charset1 != ttype_none) &&
(charset2 != ttype_none) &&
(charset1 != ttype_binary) &&
(charset2 != ttype_binary) &&
(charset1 != ttype_dynamic) &&
(charset2 != ttype_dynamic))
---
Основное, что интересовало
- Оттестить работу сервера с ICU-кодировками
- Поймать багу сервера вида
"Dynamic SQL Error
SQL error code = -804
SQLDA missing or incorrect version, or incorrect number/type of variables"
---
Система: Q6600, 4GB, RAID10 (из 4xSATA), Vista x64
Афинити сервера - 15 (разрешено юзать все 4 ядра)
Остальные настройки сервера - по умолчанию.
---
Тесты однопоточные. Каждый набор тестов работал с собственной базой данных.
Параллельно запускалось до 4 групп тестов (система грузилась практически на
все 100%)
Тестировались: блобы, массивы, текстовые колонки, бинарные типы, схемы
метаданных.
Днем, ясный пень, машина юзалась интерактивно и FB напрягали другими,
ненапряжными задачами.
---
Самая продолжительная группа (тестировались блобы c ICU-кодировкой CP943C)
работала почти неделю.
[15.02.2009 23:31:17] START
...
[22.02.2009 05:31:39]
[summary] TOTAL USER TIME: 1 day(s) 08:13:20.5027882
[summary] TOTAL KERNEL TIME: 13:45:44.5759914
[summary] TOTAL TIME : 1 day(s) 21:59:05.0787796
[summary] TOTAL WARNING COUNT:0
[summary] TOTAL ERROR COUNT :0
Здесь приведено время, которое сожрал клиентский процесс с тестами.
Эти тесты добавляют, читают и удаляют записи с BLOB-ами.
База этой группы распухла до 10.5GB
Конечная статистика одной из 3 таблиц, которые мучали эти тесты
Database "d:\Database\IBP_TEST_FB21__blobs_CP943C.GDB"
Database header page information:
Flags 0
Checksum 12345
Generation 689691
Page size 4096
ODS version 11.2
Oldest transaction 689687
Oldest active 689688
Oldest snapshot 689688
Next transaction 689689
Bumped transaction 1
Sequence number 0
Next attachment ID 206780
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Clumplet End 96
Database dialect 3
Creation date Feb 12, 2009 0:43:51
Attributes force write
TBL_CS__CP943C (160)
Primary pointer page: 671, Index root page: 672
Average record length: 0.00, total records: 33744268
Average version length: 20.91, total versions: 33744268, max versions: 1
Data pages: 853206, data page slots: 853206, average fill: 93%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 19
60 - 79% = 4
80 - 99% = 853183
Index PK_TBL_CHAR__CP943C (0)
Depth: 3, leaf buckets: 56321, nodes: 33744268
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 2
60 - 79% = 5
80 - 99% = 56313
После сборки мусора в БД
TBL_CS__CP943C (160)
Primary pointer page: 671, Index root page: 672
Average record length: 0.00, total records: 0
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 0, data page slots: 0, average fill: 0%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
Index PK_TBL_CHAR__CP943C (0)
Depth: 2, leaf buckets: 1, nodes: 0
Average data length: 0.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0
+++++++++++++++++++++++++++++++++++++
Бага "SQLDA missing or incorrect version, or incorrect number/type of
variables" несколько раз воспроизвелась, но не поймалась :-)
+++++++++++++++++++++++++++++++++++++
Процесс сервера наработал 96 часов. Утечек памяти вроде не наблюдается. Хотя
сейчас, без подключений, сервер жрет 53.3 MB.
--
Вот. Тесты хотя и относительно аггресивные, но не такие как в декабре
прошлого года. Тогда FB падал через 40 часов после начала мучений. Проверял
два раза. Тогда я круглосуточно грузил сервер под завязку тестами для
текстовых блоб полей.
В этот раз меня интересовало больше - выносливость дисков (ST3500320NS) с
новой прошивкой SN06. Время полета после последнего включения - 271 час.
Пока полет нормальный :-)
--
Коваленко Дмитрий.