Существует задача - поднять сервер с 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 Foundation\Apache2.2\bin\httpd.exe
Путь сбойного модуля: unknown
Код отчета: 038516ab-5a1d-11e1-a49d-14dae9b4fdfb

Перевожу обратно на пользовательский ХР - всё нормально.
Теперь думаю что, видимо, надо на 32-разрядной оси попробовать, но не хотелось бы терять половину памяти.
Какие-нибудь идеи есть?

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

И апач и сервер приложений 1с на 64-х разрядных системах ведут у вас себя примерно одинаково, а работают они с одной и той же конфигурацией.
Правда, апач, пишут, любит это делать  - http://forum.slicehost.com/comments.php?DiscussionID=1275, http://habrahabr.ru/blogs/server_side_optimization/75229/ (небольшой спор по этому поводу), да и платформа тоже не прочь отведать памяти, но не сами по себе, а выполняя какой-либо код. Надо смотреть в сторону конфы, наверное...

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

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

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

Мы как-то сэкономили на видеокамерах для генерального нашего..

Он сказал - ХВАТИТ ЭКОНОМИТЬ МОИ ДЕНЬГИ! :)

Теперь тратим на макс... даже если витую пару берём.. то всегда экранированную 6ой категории.

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

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

(7) если есть бизнес - значит есть деньги.

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

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

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

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

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

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

даже в монопольном режиме файловая база работает медленее...

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

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

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

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

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