Приветствую, искал мануал не нашел, nginx с directadmin жить будет, совместимость, и возможно ли?

Жить будет, только ставить нужно отдельно. Ставили такую тузлу, только юзеров надо ручками в конфиг nginx добавлять и менять потом в DNS IP на котором nginx крутится. Геморно, поэтому делаем только тем клиентам, которым нужен nginx.
Если кто знает, как подружить DA с nginx (автоматизация), будет интересно почитать.

В теории, у DA есть все возможности для того, чтобы сделать это - те же domain_create_*.sh, и так далее.
На практике - нет человека/фирмы, которая подготовит готовое решение и будет его сопровождать.

Почему же нет?! Есть и человек и фирма ;)

И где же решение? )

Большего не скажу, так как в этом форуме реклама запрещена.

Есть
Просто у покупателей денег нет, кризис и все такое

Зачем реклама? Есть реклама, а есть незаинтересованная в получении прибыли рекомендация.

Решение есть всегда, иногда даже только в голове. А вот чтобы это решение воплотить - вопрос денег.

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

Поэтому готового решения нет. Есть только ясное понимание, как это сделать. Но за небольшие деньги нет интереса этим заниматься, так как у меня имеются другие качественные решения по разгрузке сервера, которые устраивают клиентов.

PS
Не так давно я придумал одно понятие: "мода на nginx" :)
Думаю, вы поймете подоплеку этого... ;)

1. А почему? 4 процесса, использующие aio будут явно производительнее 300 процессов, использующие блокирующие read/write. Проблемы возникают только если клиент будет отдавать большие файлы, но такое на шареде вроде бы запрещено. По отдаче статики - действительно, есть костыли - паролирование, рерайты.
3. Тут полностью согласен.

Понимания мало, нужно готовое решение. разработка и сопровозждение.

PS - ага, есть такое Но оно реально помогает разгрузить впску с малым количеством памяти, просто установленное как фронтэнд. Дешево, просто и сердито.

Решение всех костылей описанных выше: по выбору кого на nginx, кого мимо. Вот вам и "заточка" под конкрентые проекты.

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

Давно использую готовое решения на DA в связке nginx+php-fpm
Машинка с 2G RAM тянет такое, от чего квад с 8G RAM вылетал с oom

Блиц цена 500$ или собирайтесь 5 человек по 100$
Пишите в ЛС

Вот это верно! Только это и может быть единственным правильным решением. Никаких apache сюда примешивать не нужно, как это любят многие...
Именно такую схему мы реализовывали одному клиенту. У него был проект в виде кучи одинаковых сайтов top100. DualXeon просто умирал. После внедрения nginx+php-fpm и полного отказа от apache клиент поправил немного свои скрипты под nginx и похоже что на сервер поместилось бы еще сто таких top100 сайтов... нагрузку как рукой смело. От автоматизации DA клиент отказался по финансовым соображениям, так как его устраивала ручная правка кофигов изредка. DA использовал только для почты. Это вариант 3 в данном мною выше описании. Для массового шареда все еще считаю его непримлемым. Хотя по указанной схеме "кого на nginx, кого мимо", наверное, вполне можно.

Проблема решается вот так

мы вообще тут про удаление нафиг apache а если ставить nginx в паре с apache то есть несколько способов.

apache придется оставить для "галочки" на главном интерфейсе, но конечно его использовать смысла нет - большинство CMS можно адаптировать под связку