Нестабильная работа 1С+Apache #596538

Существует задача - поднять сервер с Apache и настроить работу разделённых подразделений компании по тонкому клиенту в УТ11. Как временный вариант на данный момент просто стоит Apache на пользовательском компьютере с 32-разрядной WinXP и работает с базой в файловом режиме, всё стабильно. Пользователей в системе - 10 машин. Был закуплен ПК с характеристиками что-то вроде Corei5 3.3Ghz, 8Gb DDR3 исключительно для функций сервера 1С в файловом режиме. Сначала на него был установлен Linux Debian 6.0 Squeeze amd64 и входящий в репозиторий Apache. Сначала было много попыток заставить всё это работать на версии платформы 8.2.14.540, пока не выяснилось, что х64 в файловом режиме на Linux стал поддерживаться только начиная с платформы 8.2.15. В общем, всем обновлена платформа, установлен релиз 8.2.15.289, настроено подключение, розданы все права на папки 1с пользователю www-data, начали работать. Неожиданно через какое-то время Apache отбирает все 8 гигов оперативы и еще 7 гигов свапа, в базе при этом работать естественно невозможно. Происходит это резко и неожиданно. Вот вроде сидят пользователи, проводят чеки, и вдруг бац - нагрузка на проц 100 и через 3 секунды отжор всей доступной памяти. Минут 10 могут поработать нормально от силы, если совсем мало работают то больше. В WinXP такого, естественно, не было. Было сделано предположение, что wsap22.so для файлового варианта x64 линукса еще сыроват и для проверки гипотезы установлен Postgre 8.4.4 от Etersoft и база залита на него, пользователи получают доступ к базе по схеме компклиента-апачи-сервер1с-постгри. Через очередные 10 минут происходит примерно тоже самое, только всю память отжирает не процесс apache, а процесс rghost. Были предприняты попытки в логах 1с отыскать причину - но там просто какие-то пустые транзакции и проведения документов ЧекККМ. В конфе на всякий случай отключен полнотекстовый поиск, индексирование которого может надолго вешать базу - ситуация нисколько не изменилась. Далее на машину был установлен Win7 x64, скачан 2.2.21 релиз Apache для Win32 (не нашел х64 вариантов) и запущено всё это дело в файловом режиме через веб-сервер. Всё работает, но через какое-то время сервис Apache падает с записями в системном логе: Имя сбойного приложения: httpd.exe, версия: 2.2.21.0, отметка времени: 0x4e6a3015 Имя сбойного модуля: unknown, версия: 0.0.0.0, отметка времени 0x00000000 Код исключения: 0xc0000005 Смещение ошибки: 0x739ac9f1 Идентификатор сбойного процесса: 0xe34 Время запуска сбойного приложения: 0x01ccee290b67c5b6 Путь сбойного приложения: C:Program Files (x86)Apache Software FoundationApache2.2inhttpd.exe Путь сбойного модуля: unknown Код отчета: 038516ab-5a1d-11e1-a49d-14dae9b4fdfb Перевожу обратно на пользовательский ХР - всё нормально. Теперь думаю что, видимо, надо на 32-разрядной оси попробовать, но не хотелось бы терять половину памяти. Какие-нибудь идеи есть?

Если поставить дистрибутив с ядром с PAE, то ничего не потеряется(в смысле память).

И апач и сервер приложений 1с на 64-х разрядных системах ведут у вас себя примерно одинаково, а работают они с одной и той же конфигурацией. Правда, апач, пишут, любит это делать  - , (небольшой спор по этому поводу), да и платформа тоже не прочь отведать памяти, но не сами по себе, а выполняя какой-либо код. Надо смотреть в сторону конфы, наверное...

Почитал с интересом про х86-64, спасибо. По поводу конфы - её стабильная работоспособность под 32битным ХР показывает, что она не содержит однозначно вешающего систему кода типа бесконечных циклов. Вся странность поведения, скорее всего, обусловлена особенностями компиляции в разных средах. А компиляция осуществляется через модуль wsap22.so/dll от процесса апача - во всяком случае компиляция серверного когда конфигурации. Почитав разное, пришел к выводу что надо пробовать ставить на 32 бита, в данном случае х64 особо не нужна. Еще есть такая мысль - допустим, данная ошибка появилась именно в платформе 8.2.15.289. Но при этом нормальная работа под ХР объясняется тем, что веб-модуль там не обновлялся до этого релиза - там же можно его не выбирать, и по умолчанию он не выбирается. Попробую проверить версию dll-ки из ХР...

Нахера люди ставят Линукс? Чумачечие что ли..

экономят деньги владельцев бизнеса.. чтобы они могли купить на одну сигару больше... или чтобы они могли в какомнить кабаке сисястой официантке больше чаевых оставить...

Мы как-то сэкономили на видеокамерах для генерального нашего.. Он сказал - ХВАТИТ ЭКОНОМИТЬ МОИ ДЕНЬГИ! :) Теперь тратим на макс... даже если витую пару берём.. то всегда экранированную 6ой категории.

Стоимость серверных ОС от Microsoft - не всем по карману.

Ээээм... Да лан, не гони.. хочешь ссылку дам? С торрента скачаешь и ОК.. ^_________^

если есть бизнес - значит есть деньги. Конечно не обязательно их на лево и направо кидать, но есть такое понятие как "риск остановки", если от остановки на сутки компания теряет 500$ то конечно можно ставить линуху, а вот если 50000% (например на репутации) то ставить нужно не то что дешевле а то что надежнее

1с  категорически не рекомендует файловый режим и вебсервер

1с вообще не рекомендует файловый режим

не совсем так. до 5 пользователей

Я бы не сказал что линукс склонен увеличивать "риск остановки". Во всяком случае, на моём опыте так не получалось. Ну и сейчас - на Win7 тоже не заработало. Проблема повторилась на клиент-серверном режиме. Ну и, в силу известных причин, скорость работы файлового режима при небольшом числе пользователей выше.

>>> скорость работы файлового режима при небольшом числе пользователей выше даже в монопольном режиме файловая база работает медленее...

если все виндовое, то на фиша аппач, и2с используйте тоже виндвовое

>>поднять сервер с Apache и настроить работу разделённых подразделений компании по тонкому клиенту в УТ11. я чото не пойму. для работы тонкого клиента апач не нужен. апач ставят только для работы через браузер. ты уже определись что тебе надо.

тонкий нормально работает через апачи, и к стати это самый быстрый вариант, быстрее чем тонкий напрямую

Понятно ли, что в случае работы тонкого клиента напрямую с файлом не происходит фактического разделения на клиент-серверные составляющие и всё комплилируется на клиентской машине в режиме эмуляции сервера? Ну и тащить VPN чтобы обеспечить всем офисам возможность работать напрямую с файлом тоже как-то не выглядит разумно. Даже внутри одного офиса скорость работы непосредственно с файлом получается в разы медленнее, чем через апач. Тестовая конфа от Гилева с результатами теста, подтверждающая это заявление, имеется?

Кому интересно - проблема оказалась в платформе 8.2.15.289, которая некорректно работает с апачи.