Проблемы при бекапе

[nevadimka]

Во время бекапа возникает ошибка Out of memory
и система запускает OOM-Killer и начинает убивать процессы и получается что часто убивает sshd, crond где запускаются другие процеси например sweep.
База очень большая версия ФБ 1.5.3

Кто-то что-то посоветует?

[kdv]

Кто-то что-то посоветует?

посоветую
1. указать операционку
2. вариант FB (супер, классик)
3. указать размер БД. "Очень большая" - это какая, 200 гигабайт?
4. указать настройки, ИЗМЕНЕННЫЕ в firebird.conf, например databaseCachePages
5. привести информацию gstat -h database.fdb

В следующий раз, при таком скудном изложении информации, топики буду пристреливать. Хотите чтобы Вам помогли - сообщайте подробности.

p.s. в любом случае, сильно сомневаюсь. до сих пор о подобном при бэкапе слышать не доводилось.

[WildSery]

6. Бэкап делается локально или как

[nevadimka]

OS -Linux RedHat
FB - classic
size DB - 85Gb
настройки по дефолту, менял токо пути некоторые
Процесс запускается локально через крон
Database header page information:
Flags 0
Checksum 12345
Generation 691595
Page size 4096
ODS version 10.1
Oldest transaction 661185
Oldest active 691280
Oldest snapshot 691280
Next transaction 691577
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Mar 30, 2008 6:02:04
Attributes force write, no reserve

Variable header data:
Sweep interval: 0
*END*

[kdv]

и на каком этапе бэкапа происходит out of memory? Т.е. кто это вообще выдает, и докуда доходит бэкап?
Откуда взялась эта база - раньше проблем с бэкапом не было, а сейчас они бац, и появились?

Кстати, комменты:
1. размер 4к для такой базы - мало. минимум 8к.
2. флаг no reserve базе кто установил и зачем?

[nevadimka]

проблема out of memory начинается через 10 минут после начала бекапа(это обычно).
Процес бекапа не убивает - gbak( хотя 1 раз убило), но убивает скрипт запуска бекапа и свипа, в итоге не происходит ни свип ни бекап ни архивация.
Проблем не было когда БД была меньше

[Attid]

скрипт бекапа бы показал.

запусти бекап с параметром -v посмотри что последнеее будет перед ошибкой.

[nevadimka]

Кстати, комменты:
1. размер 4к для такой базы - мало. минимум 8к.
2. флаг no reserve базе кто установил и зачем?

Приняли во внимание эти моменты в ближайшее время протестируем

[Attid]

если у вас бекап не делается, то не переделаете =)

[kdv]

проблема out of memory начинается через 10 минут после начала бекапа(это обычно).

ё-мое, все клещами вытягивать приходится. вы ключик -v gbak указываете? В логе в этот момент ЧТО НАПИСАНО!

Ей-богу, 85 гиг база, и совершенно невнятное описание проблемы.

[nevadimka]

gbak -b -v -g

Свободного дискового места хватает
ОЗУ 16 г

Вот часть из лога системы:
Free swap: 2094848kB
Apr 3 04:19:07 kvhocr4 kernel: Out of Memory: Killed process 25397 (backup_sweep).
backup_sweep - скрипт который заупускает бекап а потом свип.
Этот скрипт убивается, но так как gbak не убивает то процес бекапа доходит до конца. А вот свип в итоге не запускаеться.

Этой ночью пораскидал процессы по разных скриптах. Проблемы не было.

На выходных сделаем страницу 8192 и опять попробуем одним файлом.

Вот еще ссылочки которые мне подкинули

http://tracker.firebirdsql.org/browse/CORE-870
http://tracker.firebirdsql.org/browse/CORE-973

[dimitr]

тебя просили показать консольный вывод gbak-а на момент нехватки памяти. Ведь ключик -v указан, значит вывод в stdout есть. Неужели так сложно привести последние строчки?

ЗЫ. закрадывается смутное подозрение, что stdout куда-то перенаправляется и оное "что-то" как раз и отжирает всю память.

[nevadimka]

Вот полная строчка бекапа:

gbak -b -v -g -user SYSDBA -pass masterkey firebird.gdb firebird.gbk -y backup.log

Последние строки из лога бекапа:

gbak: writing referential constraints
gbak: writing check constraints
gbak: writing SQL roles
gbak: writing sql role: THE_ROLE)
gbak: closing file, commiting, and finishing. ляляля bytes written.

[nevadimka]

Ну что же проблема не исчезла. Сделали страницу 8192, убрали флаг no reserve, разбили скрипт на части. Но во время бекапа система начинает убивать процессы изза нехватки памяти, хотя свапа еше 2г свободно как пишет системный лог. В 4.00 запускается бекап, а уже в 4.25 система на протяжении 3 минут убивает процессы, и потом через час опять 3-4 минуты. Хорошо что пока не убивает сам процесс бекапа, но это походу пока.

У кого какие идеи остались почему процесс бекапа ест так много памяти и как решить эту проблему?

[Attid]

Вот полная строчка бекапа:

gbak -b -v -g -user SYSDBA -pass masterkey firebird.gdb firebird.gbk -y backup.log

Последние строки из лога бекапа:

gbak: writing referential constraints
gbak: writing check constraints
gbak: writing SQL roles
gbak: writing sql role: THE_ROLE)
gbak: closing file, commiting, and finishing. ляляля bytes written.

в чем секретность "ляляля" ?
судя по логу бекап прошел и память уже убивает что-то там другое.
кста птичка уже 1,5,5 есть

кста ОС и ядро не указал.

в строке не указан сервер, ты бекап делаешь по локальному протоколу или вырезал опять что-то ?

[nevadimka]

1. "ляляля" -это чтобы не писать много цифр, тем более размер БД уже указывал.
2. Да бекап проходит. Но система начинает убивать процессы только вовремя бекапа, и также убивает кучу коннектов к БД.
3. Перейти на версию выше пока не позволяют.
4. ОС: Linux version 2.6.9-42.ELsmp
5. Бекап запускается через crond на том же сервере где стоит БД. Файл бекапа и лога создается на другом сервере через примаунченый раздел.