Ага, рассказывай. Когда каждый год оплата квартиры и жратва - это +30% от прошлого года, то через 2 года без соответствующей индексации зарплаты, программер просто уходит на новое место работы.
С конторки на контору всегда выгодно менять, из за большей стабильности.
Меняю работу каждые 1-2 года, все знакомые так же. Ибо для программиста фактически единственный способ поднять зарплату и ознакомиться с новыми технологиями.
На каждой новой работе слушаю байку о "карьерном росте, развитие, интересных проектах". А по факту, индексация зарплаты совершенно не соответствует инфляции и росту цен. А новые технологии оказываются за свой счет в свободное от работы время.
Хостинг не единственный бизнес, куда приходят новички и прогорают. Или же наоборот, за счет свежих идей весьма не плохо преуспевают. К примеру конкуренция в банальной строительной сфере, куда жестче, чем какой то хостинг.
Сервер для хостинга - процентов 30% от успеха. Еще нужен саппорт. Еще нужен админ. Еще нужен биллинг.
Можно начать с админа, он как правило нужный вариант сервера и посоветует.
Саппорт - тут главное уметь вежливо посылать в даль, переводя на админа только действительно проблемы, а не "у меня вордпресс чой та не работает" .
Биллинг - решать самому. Или покупать готовые решения, или на первых порах табличка клиентов в excel и все расчеты, счета и т.п в ручную .
Спорное утверждение. Число сайтов растет. А прогорают прокладки, между хостингом и клиентом. Зато ресселлеры со своими админами, со своей поддержкой, имеющие более гибкие условия от хостера - живут прекрасно.
И это устраивает всех. Датацентр избавлен от мелкой рутины, у клиентов цены ниже датацентра и есть поддержка. А ресселер имеет значительную скидку от датацента и довольных клиентов.
Пообщайтесь с http://balticservers.com , довольно вменяемый хостинг.
Блокировка за отсутствие https или не соответствия года копирайта - полный бред. Если клиент юридический - оформляйте юридический договор на хостинг, отключения за подобные письма уже вряд ли будут.
Одинаково по скорости будут. В nginx гораздо гибче конфигурация. Перешел на него где то после двух лет использования lighttpd , в общем не пожалел ни разу.
Единственный минус - нет cgi-bin, надо делать через враппер. А во всем остальном, лайт проигрывает. Поддержка слабая, фактически не развивается. В настройке лайт гораздо легче, но там и настраивать особо нечего.
Ну кто же спорит, учитывая, что у ТС дисковое пространство всего 50 гиг :D А так, тот же longblob может содержать 4 Gb данных, при индексе на первичный ключ типа longint - 32 байта. Так что и терабайт запросто можно хранить в базе, имея на сервере всего пару гиг памяти.
Поэтому подсчет число соединений * размера базы = полностью не верным.
Примерно так:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 32
MaxClients 32
MaxRequestsPerChild 1024
MaxClients - число одновременно выполняемых запросов.
Еще можно попробовать KeepAliveTimeout установить в 0 или в 2 , что бы не висели долго процессы.
Так же наверное можно выключить следующее:
LoadModule ldap_module modules/mod_ldap.so
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
Потому что нет таких простых и понятных решений. А уж тем более для mysql, где все от запросов зависит. Размер базы там вообще не влияет на потребляемые ресурсы. База хоть 100 гиг может быть, а выборка по индексу сожрет пару мег памяти. И наооброт, в паре простеньких таблиц с тысячей записей, выборка с джойнами превратится в сравнение сотен миллионов строк данных и пожиранием всей оперативки.
А в апаче какие настройки ?
MaxRequestsPerChild - это через сколько запросов перегружать процесс.
"apachectl -V" в консоли, что бы выяснить, какой именно модуль включен. Ну и уже того модуля конфигурацию смотреть, сколько разрешено процессов и т.п.
Ерунда полнейшая. Размер потребляемой памяти зависит от структуры таблиц, запросов, настроек самого sql сервера. А не от размера базы.
На скрине куча php процессов. Почему ? Если апаче, то php должен работать через mod_php. А если уж cgi - то тогда php-fpm + nginx или тонкая сборка апача без кучи лишних модулей.
Плюс опять же по скрину, php забрал весь процессор и скорее всего и всю память.
Так что копать в сторону апаче и пхп, почему плодятся и пожирают память процессы. А mysql в данном случае трогать в последнюю очередь, только для оптимизации быстродействия ответа.
Установите в апача максимально число запросов в 20, перегрузите сервер, смотрите как потом будет потребление памяти. Если памяти куча, а вэб сервер стал выдавать ответы медленно - можно еще чуть увеличить процессов, скажем до 25. И так пока не дойдете до 90% занятости памяти.
Ну а дальше уже свои скрипты оптимизировать.
Ну вот нарастите до гигабайта, то может быть сайт в вашей подписи сможет даже картинку отобразить. А то пока тяжко ему, html отработать :D
