Страница 1 из 2
Ошибка cannot start thread
Добавлено: 23 апр 2008, 09:36
Olegblch
Доброго всем времени суток. В общем ситуация следущая...
На сервере Firebird 1.5.2.4731 есть несколько БД. Одна - рабочая, которая используется непрерывно системой контроля доступом (фиксирует все события с проходных в организации и проч.). Остальные - архивные за прошлые года (в них события обрезаны за год). К этим базам идет обращение из приложений, установленных на компьютерах пользователей, для выборки этих событий.
Все работало нормально уже наверное лет 5.
Примерно 2 недели назад приложения перестали цепляться к архивным базам, с рабочей же базой соединяются свободно.
Попробовал соединиться с архивными базами через IBExpert на сервере, в результате - сообщение:
Unsuccessful execution caused by a system error that precludes successful exception of subsequent statements.
internal gds software consistency check (cannot start thread)
После перезапуска сервера базы опять нормально коннектятся... но на время, причем это время может быть 3 дня (после выходных), а может быть полдня.
С базами все нормально - проверял у себя на машине (копировал базы себе), приложения к ним коннектятся, IBExpert соединяется...
В чем может быть оказия? Почему с рабочей базой нет проблем, только с архивными...
Добавлено: 23 апр 2008, 10:12
dimitr
размер страничного кеша для архивных баз установлен большим? Если у сервера есть утечка памяти, то может к именно такому эффекту приводить.
Добавлено: 23 апр 2008, 10:52
Olegblch
А размер страничного кеша для каждой базы данных разный? если да, то где это можно посмотреть?
Все базы лежат на сервере.
А утечка происходит имеется ввиду у сервера Firebird или у машины?
Добавлено: 23 апр 2008, 11:02
Tonal
Какая ОС?
Какой вариант сервера Super/Classic?
Добавлено: 23 апр 2008, 11:32
Olegblch
ОС - Windows 2000 5.00.2195 SP3
Добавлено: 23 апр 2008, 11:45
kdv
Примерно 2 недели назад приложения перестали цепляться к архивным базам
можете вспомнить, что меняли 2 недели назад, вообще?
Добавлено: 23 апр 2008, 11:51
Olegblch
да в том-то и дело, что ничего на сервере не делали. на сервер обращаемся редко, в основном только чтобы подключиться к удаленному компьютеру на проходных, которые находятся в одной подсети вместе с ним...
Добавлено: 23 апр 2008, 12:24
Olegblch
dimitr писал(а): Если у сервера есть утечка памяти, то может к именно такому эффекту приводить.
как-то можно выявить эту утечку памяти?
Добавлено: 23 апр 2008, 12:27
kdv
как-то можно выявить эту утечку памяти?
как минимум, посмотреть в Task Manager.
Добавлено: 23 апр 2008, 12:31
Olegblch
kdv писал(а):как-то можно выявить эту утечку памяти?
как минимум, посмотреть в Task Manager.
да в диспетчере задач вроде все ровно...
Добавлено: 23 апр 2008, 15:26
Olegblch
Tonal писал(а):Какая ОС?
Какой вариант сервера Super/Classic?
SuperServer
Добавлено: 23 апр 2008, 16:03
Olegblch
Сейчас в конце рабочего дня опять базы начали коннетиться. Возможно, сейчас нет обращений к серверу с рабочих станций, поэтому...
Добавлено: 23 апр 2008, 16:08
kdv
так сколько сервер памяти потребляет? у вас в конфиге на сортировку около 250мб выделено, и кэш 65536, т.е. при размере страницы 8к. по 524мб на каждую открытую базу. Может все-таки действительно процесс fbserver спотыкается когда 2 гигабайта памяти отъедает?
p.s. почему приходится информацию клещами вытаскивать? Кому проблему надо решать?
Добавлено: 23 апр 2008, 18:20
hvlad
А теперь считаем открытые БД - рабочая, первый архив... на 3-м архиве оно и помрёт из-за нехватки виртуалки, ибо 4 * 524 > 2048
Добавлено: 23 апр 2008, 20:01
kdv
я об чем и говорю.
Добавлено: 24 апр 2008, 08:02
Olegblch
kdv писал(а):так сколько сервер памяти потребляет? у вас в конфиге на сортировку около 250мб выделено, и кэш 65536, т.е. при размере страницы 8к. по 524мб на каждую открытую базу. Может все-таки действительно процесс fbserver спотыкается когда 2 гигабайта памяти отъедает?
p.s. почему приходится информацию клещами вытаскивать? Кому проблему надо решать?
Прошу прощения, если несвоевременно отвечал на задаваемые вопросы, вроде бы старался быстро ответить.
На сервере памяти пожирается около 1Г (сейчас я думаю еще никто не цепляет архивную базу). При запуске приложения потребление увеличивается на 500 метров.
А теперь считаем открытые БД - рабочая, первый архив... на 3-м архиве оно и помрёт из-за нехватки виртуалки, ибо 4 * 524 > 2048
На самом деле приложение в основном обращается либо к рабочей либо только к одной из архивных баз (не ко всем 3). Правда если сразу несколько пользователей будут обращаться к базам... Т.е. вы предлагаете увеличить размер виртуальной памяти для диска, где базы лежат на сервере?
Добавлено: 24 апр 2008, 09:35
Olegblch
что-то про размер виртуальной памяти для диска, где базы лежат на сервере, я сморозил спросони.
На сервере оперативки 2Г. Файл подкачки изменил на 3072-4095М. (было 1024-4092). Но не помогло...
При использовании на сервере памяти сверх объема оперативки приложения перестают соединяться с архивной базой (с рабочей соединяется, но она меньше, пока что
).
Добавлено: 24 апр 2008, 10:20
hvlad
Детсад, ей богу...
На win32 размер адр. пространства любого процесса ограничен 2GB. Будь у тебя хоть 150GB RAM, больше чем 2GB виртуальной памяти ты отдельному процессу не отдашь.
И в task manager нужно смотреть именно на неё, это уже на всех заборах написано
Уменьшай DefaultDbCachePages в firebird.conf и прочти наконец-то хоть что-то про FB, про Win32, про хоть что-нибудь
Добавлено: 24 апр 2008, 10:48
Olegblch
Ладно, спасибо, что вправили мозги
Виртуальная память как раз и используется до предела под 2Г.
Какое значение DefaultDbCachePages лучше установить?
Добавлено: 24 апр 2008, 10:50
hvlad
Olegblch писал(а):Ладно, спасибо, что вправили мозги
Виртуальная память как раз и используется до предела под 2Г.
Какое значение DefaultDbCachePages лучше установить?
Вот, нормальная адекватная реакция, всем бы так
Т.к. у тебя FB 1.5.2, то более 10000 не рекомендуется.