Re: [sisyphus] ограничение ресурсов firebird

Re: [sisyphus] ограничение ресурсов firebird

[Sergey Shilov]

> > Могут помочь эксперименты с параметром instances в файле
> > /etc/xinetd.d/firebird. По умолчанию данный параметр в файле
> > отсутствует и равен UNLIMITED, что ни есть хорошо. См. man
> > xinetd.conf
>
> У человека суперсервер (ibserver), а Вы ему такое советуете ;)

Согласен, что не прав относительно супера.
Вообще для юникс системы лучше классика. Проблем будет меньше.
Эта тема больше для epsylon.public.interbase - там Гуру живут.



--
С уважением
Сергей Шилов

Re: [sisyphus] ограничение ресурсов firebird

[Sergey Shilov]

В сообщении от 2 Июнь 2004 13:27 Salavat Yarmukhametov 
написал(a):

> Э... можно поподробней - чем лучше? 
Если очень коротко и строго "по личному мнению" то:
1. Многопроцессность (КС) роднее для ..НИКС чем многопоточность 
(СС).
2. "Зависший" по каким либо причинам клиентский коннект на на 
базу (КС) не мешает другим работать и легко поддается убийству 
средствами системы, не "обламывая" при этом коннектов остальным 
клиентам (нельзя в супере клиентский тред грохнуть).
3. Механизм запуска КС (из под xinetd) вроде как тоже роднее и 
надежнее для ..НИКС.
4. КС существует поболе СС, что тоже аргумент.

> смогут ли стартовать новые процессы 
> ibserver, если уже запущенный занял 97% процессора.
ib_inet_server смогут, но ЦПУ не резиновое.

> Тот бухгалтерский софт на самом деле кривой. На небольшой базе
> не самый сложный запрос (бухгалтера называют его "оборотная
> ведость" - что это - я не знаю)
"оборотка" - апофеоз учета (хуже для вычислительной системы 
только "шахматка") тут имеет смысл "слегка" глянуть на теорию 
бухучета
> заставляет процесс ibserver 
> есть 98-100% цпу.
А вот за 100% цпу надо "хацкерам" по пальцам  линейкой. Кривизной 
архитектуры базы попахивает.

> В зависах оказалось виновато железо - проц. 
:-)

-- 
С уважением
Сергей Шилов

Re: [sisyphus] ограничение ресурсов firebird

[Salavat Yarmukhametov]

On Mon, May 31, 2004 at 01:01:51PM +0300, Sergey Shilov wrote:
> > > Могут помочь эксперименты с параметром instances в файле
> > > /etc/xinetd.d/firebird. По умолчанию данный параметр в файле
> > > отсутствует и равен UNLIMITED, что ни есть хорошо. См. man
> > > xinetd.conf
> >
> > У человека суперсервер (ibserver), а Вы ему такое советуете ;)
> 
> Согласен, что не прав относительно супера.
> Вообще для юникс системы лучше классика. Проблем будет меньше.

Э... можно поподробней - чем лучше? В моём случае - кривой бух.софт его
пользующий - смогут ли стартовать новые процессы ibserver, если уже
запущенный занял 97% процессора.

> Эта тема больше для epsylon.public.interbase - там Гуру живут.

Тот бухгалтерский софт на самом деле кривой. На небольшой базе не самый
сложный запрос (бухгалтера называют его "оборотная ведость" - что это - я
не знаю) заставляет процесс ibserver есть 98-100% цпу. В зависах оказалось
виновато железо - проц. перегревался из-за плохого контакта с радитором.
Смазал пастой - не виснет.

--
Salavat Yarmukhametov
Jabber: salik@jabber.ru
ICQ:	21144441

Re[2]: [sisyphus] ÏÇÒÁÎÉÞÅÎÉÅ ÒÅÓÕÒÓÏ× firebird

[óÅÒÇÅÊ óÉÌÁÎÔØÅ×]

Здравствуйте, Salavat Yarmukhametov.

Отвечаю на Ваше сообщение "[sisyphus] ограничение ресурсов firebird" от 02.06.2004 16:27:

SY> Тот бухгалтерский софт на самом деле кривой. На небольшой базе не самый
SY> сложный запрос (бухгалтера называют его "оборотная ведость" - что это - я
SY> не знаю) заставляет процесс ibserver есть 98-100% цпу. В зависах оказалось
SY> виновато железо - проц. перегревался из-за плохого контакта с радитором.
SY> Смазал пастой - не виснет.
А периодическая профилактика базы делается ?
На предмет check\sweep, backup\restore, set statistics и т.п. ?

Ну, пока...            Сергей Силантьев (MailTo:Serj@Kmez.Ru) ICQ:11144549
HTTP://WWW.KMEZ.RU                                       2:5010/53@Fidonet

Re: [sisyphus] ограничение ресурсов firebird

[Salavat Yarmukhametov]

On Wed, Jun 02, 2004 at 06:02:49PM +0600, Сергей Силантьев wrote:
> Здравствуйте, Salavat Yarmukhametov.
> 
> Отвечаю на Ваше сообщение "[sisyphus] ограничение ресурсов firebird" от 02.06.2004 16:27:
> 
> SY> Тот бухгалтерский софт на самом деле кривой. На небольшой базе не самый
> SY> сложный запрос (бухгалтера называют его "оборотная ведость" - что это - я
> SY> не знаю) заставляет процесс ibserver есть 98-100% цпу. В зависах оказалось
> SY> виновато железо - проц. перегревался из-за плохого контакта с радитором.
> SY> Смазал пастой - не виснет.
> А периодическая профилактика базы делается ?
> На предмет check\sweep, backup\restore, set statistics и т.п. ?

база пока в обкатке 2 недели. поэтому смысла в профилактике я пока не
вижу.

> 
> Ну, пока...            Сергей Силантьев (MailTo:Serj@Kmez.Ru) ICQ:11144549
> HTTP://WWW.KMEZ.RU                                       2:5010/53@Fidonet
> 
--
Salavat Yarmukhametov
Jabber: salik@jabber.ru
ICQ:	21144441

Re: [sisyphus] ограничение ресурсов firebird

[Алексей Любимов]

>Если очень коротко и строго "по личному мнению" то:
>1. Многопроцессность (КС) роднее для ..НИКС чем многопоточность 
>(СС).
>2. "Зависший" по каким либо причинам клиентский коннект на на 
>базу (КС) не мешает другим работать и легко поддается убийству 
>средствами системы, не "обламывая" при этом коннектов остальным 
>клиентам (нельзя в супере клиентский тред грохнуть).
>3. Механизм запуска КС (из под xinetd) вроде как тоже роднее и 
>надежнее для ..НИКС.
>4. КС существует поболе СС, что тоже аргумент.
>
>  
>
5. на smp работает только классика.

>  
>

Re: [sisyphus] ограничение ресурсов firebird

[Eugene Prokopiev]

Sergey Shilov пишет:

> 2. "Зависший" по каким либо причинам клиентский коннект на на 
> базу (КС) не мешает другим работать и легко поддается убийству 
> средствами системы, не "обламывая" при этом коннектов остальным 
> клиентам (нельзя в супере клиентский тред грохнуть).

В классике можно, но страшно. Бывали случаи (не у меня), когда от этого 
билась БД. Лучше уж ему приоритет понизить или порт прикрыть - довести 
до самоубийства, короче ;) Правда, про закрытый порт он вспомнит, только 
когда отработает запрос.

Кстати, а какие есть способы принудительно прикрыть сокет (по аналогии с 
KILL), не считая iptables? ;)

-- 
С уважением, Прокопьев Евгений