Позырив на это безобразие, подумал - чем ДЕ не шутит, и тормознул
работающий сервис FB2.5 (32bit)
У тебя работающий сервис от какого имени запускается? LocalSystem?
instsvc install -auto -superserver -z -login firebird emanov
:-)
ЗЫ. Влад что-то делал на этот счет, но я уже не помню,
Здравствуйте, уважаемые.
Накануне пятницы задам глупый вопрос. Просьба сильно не пинать
Вводная:
имеется сервер на базе Intel D805, Centos 5.3,
FirebirdSS-2.1.3.18156-0.i686 брал с http://www.dqteam.com/fb2/ сборка
от Sergey Mereutsa.
Обратил внимание, что при работе GBAK
Привет!
Обратил внимание, что при работе GBAK утилита top показывает 200%
использования CPU. До сего дня просто не интересовался.
Вопрос:
Как такое возможно? Напомню: FB SuperServer
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глючит и плющит нипадеццки
On Thu, 16 Jul 2009 12:40:45 +0500, Sergey Mereutsa
gebele...@gmail.com wrote:
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глючит и плющит нипадеццки и он врёт
2) gbak использует 2 нити, обе хавают по ядру на 100%
Ну слава Богу, с головой значит у меня все в
Это опять я. Не пугайтесь :)
Я тут затянулсо недецким смыслом двух API функций
isc_vax_integer/isc_portable_integer и набрел на код определения длины блоб
поля через
isc_blob_info+isc_info_blob_total_lengthisc_info_blob_total_length
Длина возвращается в 4 байтах. Не зависимо от разрядности
Гоголь Дмитрий wrote:
2) gbak использует 2 нити, обе хавают по ядру на 100%
оно так бывает?
Нет.
--
Дмитрий Еманов
Kovalenko Dmitry wrote:
То есть сервер длину более чем 4GB-1 не переварит
А если мне не изменяет моск, были заявы на поддержку блобов с длиной
более 4GB.
Вот именно что заявы :-) Это не единственное ограничение в 4ГБ для
блоба, есть и другие, насколько я помню. Т.е. это пока фича больше
On Thu, 16 Jul 2009 16:08:05 +0500, Dmitry Yemanov
dim...@users.sf.net wrote:
Гоголь Дмитрий wrote:
2) gbak использует 2 нити, обе хавают по ядру на 100%
оно так бывает?
Нет.
А через ServicesAPI?
Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс,
если
Кто виноватЪ и что делатЬ?
ЗабитЬ до поры до времени.
Н, ща занесу в трекер со статусом АХТУНГ! :-)
---
Я щас в очередной раз тупил над алгоритмом RowsAffected
П##т, я каждый раз понимаю что все у всех написано через жопу.
isc_info_sql_records возвращает блок с внутренними
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не будет.
Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс,
Два
óÅÊÞÁÓ ÐÒÏ×ÅÒÑÌ: ÅÓÌÉ ÚÁÐÕÓËÁÔØ gbak Ó ËÌÀÞÏÍ -se, ÔÏ 200% ÎÁ ÐÒÏÃÅÓÓ,
ÅÓÌÉ ÂÅÚ ÔÁËÏ×ÏÇÏ - 100%.
ÓÔÅÓÎÑÀÓØ ÓÐÒÏÓÉÔØ: ÐÏÌÎÕÀ ÓÔÒÏËÕ ÚÁÐÕÓËÁ Ó ËÌÀÞÅÍ -se ÍÏÖÎÏ Õ×ÉÄÅÔØ?
ÒÁÚ×Å ÞÔÏ ÐÁÒÏÌØ ÍÏÖÎÏ ÐÒÏÐÕÓÔÉÔØ :-)
On Thu, 16 Jul 2009 17:22:28 +0500, Dmitry Yemanov
dim...@users.sf.net wrote:
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не
А gbak и не вижу, есть процесс fbserver и он грузит до 200%.
Чтобы не быть голословным: http://alf2.nm.ru/fb_top.gif
--
Гоголь Дмитрий
ÄÁ ÔÁÍ ×ÓÅ ÔÏ ÖÅ ÓÁÍÏÅ ÔÏÌØËÏ ÄÏÂÁ×ÌÑÅÔÓÑ -se hostname:service_mgr
ÏË, ÐÅÒÅÆÒÁÚÉÒÕÀ (ÞÔÏ ÈÏÔÅÌ Õ×ÉÄÅÔØ):
ÐÕÔØ Ë âä - ÔÏÞÎÏ ÕËÁÚÁÎ ÌÏËÁÌØÎÙÊ, ÂÅÚ hostname:?
14 matches
Mail list logo
