Проблема выглядит следующим образом:
Есть ASA9.02 сервер на Linux RedHat5. На нем же стоит SQLAnywhere 10+PHP+Апач. 10-й sybase потребовался т.к. только начиная с него появилось расширение php_sqlanywhere для пхп для linux'а. Т.е. из пхп идет использование SA10 в качестве клиента и для использования нативного подключения к серверу ASA9. Подключение идет через TCPIP (да, сам на себя через сетевой уровень), не через sharedmemory.

Все вроде работает зашибательно. Однако, на активной нагрузке (это единственное что приходит на ум) в определенный момент все встало. В логе апаче наблюдаю ошибки от PHP суть которых сводится к тому, что подключение к БД не удалось о чем сообщает драйвер Sybase от 10-ки. Буквально это звучит так: "Connection error: Insufficient system resources - failed to allocate a SYSV semaphore"
Во-первых, непонятно кому не хватило семафоров, серверу или драйверу? Во-вторых куда они делись и как добавить их количество?

Ко всему прочему в логе сервера вижу постоянные сообщения о том, что "клиент абнормально отсоединился, куда-то делся короче". Я понимаю, что не происходит грамотного отключения от БД, и подключившийся к БД поток кем-то убивается и от него остается висеть семафор. Это судя по всему и есть причина.
Это все предыстория была.

Подключение из PHP идет функцией sqlanywhere_pconnect. С помощью нее организуется пул подключений. Возможно я безграмотно им воспользовался, т.к. отключений от БД нигде нет. Есть похожие функции sybase_pconnect и прочие, так что у меня вопрос не столько по АСА, сколько в принципе по сабейзовским пулам и работе с ними из PHP, т.к. сделаны они наверно аналогично.
Каким образом нужно штатно отключаться от БД из PHP, если мы используем подключения при помощи *_pconnect? Ну и вообще, какие могут быть советы в данной ситуации. Т.к. система может работать исправно сутками без всяких нареканий, а потом бац... Семафоры эти..

2)sqlanywhere_pconnect это псевдоним на sasql_pconnect. Переделали на sasql ничего не изменилось.
3)Про sybase_ функции я упомянул, чтобы привлечь внимание специалистов по ASE, предполагая, что механизм пулизации и использования семафоров там может быть идентичный АСАшному.
4) Выяснилось, что отключаться при постоянных подключениях не нужно и не получится, это должен делать менеджер пула...
5) Туманно описано как раз наоборот. Что pconnect лучше использовать на высоконагруженных серверах для того, чтобы сэкономить ресурсы на постоянных подключениях/отключениях.

Качнул исходники PHP_SQLANYWHERE библиотеки, вычитал что были исправления в функции pconnect от октября 2009. Обновил на сервере. Не помогло. Опять раскорячилось.

Я видел это. Собсно и остается открытым вопрос: как сделать так, чтобы апач не килил своих детей, которые имеют подключения. Первопричина где-то рядом, но я владею только симптоматикой.
Сейчас вообще решили без пула сделать. Семафоры остаются все равно, не смотря на то, что висящих коннектов к БД нет...

Да, это тоже видел.

Ситуация следующая.
Если не использовать пул, то все встает гораздо быстрее. Семафоры все кончаются и усе. Буквально за 5 минут. Добавлением в системе семафоров это не лечится, т.к. "сколько волка не корми он все в лес смотрит". Просто оттягивается момент стопа. С пулом живет дольше, т.к. меньше подключений используется и как следствие с меньшей скоростью остаются семафоры.
Настройки пхп тут невлиятельны, и так, и сяк...
Непонятно в какую сторону двигаться. То ли апачу объяснять, чтобы он не килил своих детей, то ли на стороне ПХП некорректная работа, то ли библиотека DBCAPI от sybase дурит.
И вот еще. Sybase рекомендует для апача 2.х использовать thread safe версию драйвера. Не знаю влияет ли, но на сервере phpinfo выдает Thread Safety => disabled.

Там советуют обновиться . Посмотрим что получится. Как слепой ежик в черном лесу, с этими линухами...

Да пингвины-то не причем. Просто познания в линуксовых инструментах у меня не сильные. Выяснил недавно, что можно не только мониторить семафоры в системе, но и оставшийся "мусор" чикать. А то ведь приходилось железку грузить...

Тут вот какое развитие с этой темой получилось. Действительно, семафоры оседали в системе из-за того, что апач убивал лишние потоки, а SA клиент видимо не имел обработчика этого убития. Увеличив параметр MaxSpareServers достаточно сильно (практически до MaxClients), и уменьшив MinSpareServers до 5 я добился того, что веб-сервер практически не занимается убитием своих детей. Они просто висят в памяти вхолостую. Плюс ко всему прочему обновил SA10 и php_sqlanywhere драйвер. Кстати, этот драйвер родился где-то за последние два-три года только. Все вроде работает, все семафоры (ipcs -s -t) регулярно обновляются, ничего не оседает.
НО! Если я меняю вызовы sqlanywhere_[functions] на sasql_[functions], то в системе активно остаются висеть семафоры, с каждым новым запросом они прибывают и прибывают.. И через 5 минут в системе все "заср@но" и встает в раскоряку. Странно все это. В исходниках вроде вычитал, что sqlanywhere_ сделаны всего лишь псевдонимами к sasql_. А оно вот ведь как...

Ggg_oldЖесть какая. А на линуксе как-то odbc заюзать нельзя? Я в линуксе "ноль на массе", но мало ли.
И конечно же продолжайте пожестче развивать ваш топик на сайбезовом форуме, может кто и почешется.
В линуксе есть аналоги ODBC, типа unixODBC и прочие. Но это все костыли еще те. Местами глюк на глюке. Лучше уж использовать нативный драйвер от производителя (php_sqlanywhere), чем прослойки организовывать.

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

Я вот одного пока не понял, когда заходит речь о семафорах, то необходимо кое-чего уточнить. Оказывается один клиент АСА использует не столько семафор, сколько пакет-массив семафоров. Два потока клиентов - два массива семафоров и т.д. В RedHatEL5 по умолчанию в системе есть 128 массивов семафоров по 250 штук в каждом. Т.е. на самом деле семафоров в системе до фига, но используются они крайне не понятно(не эффективно?). 128 штук при большой нагрузке выбивается запросо. Но остается вопрос, это что, действительно для работы одного коннекта SA-клиента с ПХП нужен пакет из 250 семафоров???!!! Не думаю, что действительно предполагается такое использование семафорного ресурса ОС. В противном случае у меня кривые руки и я не знаю какого-то ключевого секрета. Режим работы апача prefork. Может надо его перекомпилить на worker режим?

P.S.: Неужели никто не использует связку Linux+Apache+PHP+ASA(ASE)? Может ну его в баню АСА и перейти на MySQL?

Ерунда какая-то.
Думал, что проблема из-за управления потоками на апаче 2.2. Выкачал с инета исходники apache 1.3.42, php 5.3.2, php_sqlanywhere 2.0.9. В пхпшном коде заменил все вызовы sqlanywhere_ на sasql_, чтобы уж тестить с новым интерфейсом. Все перекомпилировал со статической компоновкой модулей. И... И ничего приятного. Редко возникают падения детей апача. В его логе это выглядит, как "[notice] child pid XXXXX exit signal Segmentation fault (11)". Т.е. с новыми функциями библиотеки php_sqlanywhere отписывается такая ерунда, в случае со старыми функциями ничего не отписывается, но в обоих случаях из-за некорректного завершения потока остаются не освобожденные семафоры.
Нужно менять драйвер доступа из PHP к SA? Или заниматься backtrace'ом при помощи gdb и искать ошибку? А может все дело в слишком "многопоточном" железе, один 4х-ядерный Xeon, и что-то где-то кого-то обгоняет? А самое главное не могу нащупать однозначной причинно-следственной связи.

Последнюю проблему решил. По совету разработчиков из iAnywhere при вызове sasql_query в явном виде указал третий параметр SA_USE_RESULT. По умолчанию, если он не указывается, он считается за SA_STORE_RESULT. Segmentation fault прекратились, выборки отрабатывают уже несколько суток подряд, в error_log чистота и порядок. Возможно это связано с тем, что все выборки из ПХП у меня идут не запросами SELECT, а через вызовы ХП call. Вот такой нюанс.

А убитие апачем своих потоков предотвратил кардинально, установил в его настройках MaxClients=MaxSpareServers.

Тихо сам с собою беседу я веду.
А вот и еще одного жука за хвост поймали. Если сделать последовательно два запроса sasql_query(..,..,SA_USE_RESULT), а потом попытаться отфетчить и закрыть сначала один, а потом второй, то опять вываливается Segmentation fault.
Так что висящие семафоры - это всего лишь следствие.

Хм, да ничем не закончилась.
От persistent подключений отказались, перешли на подключение/отключение к БД на каждом запросе. Иногда в логе апаче видно segmentation fault его потока, плюс в системе подвисает навечно заюзаный семафор. Эпизодически приходится гасить апач и убивать все семафоры, оставшиеся после его остановки. Оформили скриптом. Неправильно это.

Отпишите плиз версии, ОС, дров АСА, сервера АСА, веб-сервера/пхп и т.п.

ОС: Linux RedHat 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64

веб-сервер: apache 2.2.3

php: 5.1.6

PHP SQLAnywhere driver version: 2.0.8.0

SQLAnywhere client version: 10.0.1.4061

Сервер с СУБД та же машина

СУБД: Adaptive Server Anywhere Version 9.0.2.3748

Интерфейс доступа в драйвере взяли новый, который sasql, а не sqlanywhere. С ним хоть как-то заработало.