 |
Архив конференции ukr.comp.dbms.informix |
Re: max of sessid?
|
From |
Igor Zavgorodny <daugava@torba.com> |
|
Date |
Mon, 17 Jun 2002 19:06:37 +0300 |
|
Organization |
Svit Online (post does not reflect views of Golden Telecom) |
Vasyl Shulzhenko wrote:
>"Igor Zavgorodny" <daugava@torba.com> wrote in message
>3D0DF669.8040805@torba.com">news:3D0DF669.8040805@torba.com...
>
>
>>Vasyl Shulzhenko wrote:
>>
>>
>>>"Igor Zaiets" <zaiets@ukr.net> wrote in message
>>>aeklek$a6q$1@castle.profix.kiev.ua">news:aeklek$a6q$1@castle.profix.kiev.ua...
>>>
>>>
>>>>Внимательно смотрите релизы!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>Это для 9.30
>>>>
>>>>
>>>Так и где тут ответ на вопрос ?
>>>Мне кажется, Вячеслав спрашивал другое.
>>>А что будет, если sid переполнится ? А ничего не будет ("я так думаю" :).
>>>Зашкалит и пойдет в минус. Да и достучаться до максимума (integer)
>>>тяжеловато. Если каждую секунду коннектиться и отсоединяться, то лет так
>>>
>>>
>на
>
>
>>>60 должно хватить :))
>>>
>>>
>>Сразу видно теоретика :-). Как человек от сохи, я практически полностью
>>не согласен с предыдущим оратором. Единственное справедливое
>>утверждение - "ничего не будет". Зашкалит оно на 32767, и далее уйдет
>>не в минус, а начнет опять отсчитыватся от единицы, занимая "свободные"
>>session id. Почему я настаиваю на цифре 32767 ? По 2-ум причинам:
>>
>>
>
>Сразу видно старого практика :))
>Да еще и ...с нестабильным сервером Информикс :))
>
Причина падений моего 7.3 нашлась уже когда я на нее плюнул и смирился,
после 2-ух летней борьбы с саппортом.
Как оказалось, виноват был Read Ahead, хотя в описании бага #154004
вовсю обвиняется компилятор cc для интеловой соляры, оный баг я
переживал и на SCO, есть данные о его проявлениях и на HP-UXe. Сейчас,
после перехода на Соляру, я ни разу с ним не встретился, несмотря на
наличие в описании бага и 9-ки.
>Тут же тебе пример:
>
>Informix Dynamic Server Version 7.31.TC2 -- On-Line -- Up 21 days
>
>
>02:49:51 -- 395648 Kbytes
>Userthreads
>address flags sessid user tty wait tout locks nreads
>nwrites
>....
>202ae4c8 Y--P--- 1681298 dbadmin SENCHUK 20fc33c8 0 1 340 372
>202af380 Y--P--- 1689745 dbadmin SENCHUK 21588880 0 1 0 0
>202b0238 Y--P--- 1706444 dbadmin DBHOST 204892b8 0 1 2460
>2460
>202b0c08 Y--P--- 1681072 dbadmin SENCHUK 20747a88 0 1 646 694
>202b50b8 Y--P--- 1710112 dbadmin ROSSOL 211f36b0 0 1 0 0
>202b5f70 Y--P--- 1681056 dbadmin SENCHUK 21406428 0 2 0 0
>202b6940 Y--P--- 1711029 dbadmin ROSSOL 21166f20 0 1 0 0
>202b77f8 Y--P--- 1710841 dbadmin DEM 210be230 0 1 2345
>2624
> 16 active, 128 total, 23 maximum concurrent
>
>Надеюсь веришь, что цифры я не менял ?
>
Верю, мой тест на 9-ке уже подбирается к ним вплотную. В очередной раз
сыплю голову пеплом. Жалко, что я 7.2 дней 5 назад убил, такбы пепла
могло оказаться и больше :-).
>>1.В релизе, приведенном г-ном Зайцем, упоминалось " 32K user thread".
>>
>Это говорит совсем о другом - что не может быть ОДНОВРЕМЕННО более 32К
>пользовательских нитей (кстати, нитей, а не сессий).
>
Это понятно, но это косвенно подтверждает, что более 32К session id не
нужно ;-).
>>2. Из собственного древнего опыта на 7.2, к сожалению 7.3 у меня умирал
>>быстрее, чем исчерпывались оные 32К.
>>Разочаровывающий опыт :))
>>
Сервер подымался на автомате в течение минуты (если падал от утомившего
меня бага), с отсылкой мне сообщения. Впрочем, по другим причинам он и
не падал. Порылся в архиве своих 7.31-ассертов, самый большой аптайм -
77 дней, максимальное sessid - 29064 :-).
>>P.S. На всякий случай запустил тест под названием "каждую секунду
>>коннектиться и отсоединяться". Если, я прав 60 лет истекут еще до
>>завтрашнего утра :-).
>>
>
>60сек*60мин*24часа*365дней=31536000 за год.
>2143000000 (точнее не помню) / 31536000 ~ 67 лет
>Где я не прав ?
>
>
Круглые цифры надо знать наизусть :-). 68.09626 лет. Сейчас мой тест
работает в таком режиме, чтобы достигнуть "предела" за 14 дней.
Regards, Igor.
Украинская баннерная сеть