Общего решения на все случаи жизни нет.
Можно разделить по пользователям, как сказал [umka]. Но и тут, если у вас php выполняется не как модуль apache под общим юзером.
По mysql тоже вариант с percona хорош.
Но всё это отдельно не имеет смысла. Вопрос достаточно глубокий, как считать нагрузку. Решения есть, но все не идеальны. У хостеров даже бывают сапописные скрипты, которые собирают статистику в нужном им формате.
Проще включить /server-status у apache и смотреть в момент нагрузки, к каким сайтам обращаются. Можно так же смотреть это по логам.
По mysql можно добавить префикс к базам, как у хостеров... в духе user_DB
Будет понятно, какому пользователю относится база при просмотре тяжёлых запросов. Ну а дальше в ручную найти в конфигурационных файлах сайта, который её использует.
Это всё гораздо проще, чем углубляться в точный подсчёт статистики, ведь он потребует смену программного обеспечения на сервере и тонкой настройки.
Вопрос тут лишь в критичности работы сайта 24x7 (устранение проблем, обновление ПО, устранение обнаруженных уязвимостей и т.п.)
Вопрос тут не в деньгах, а на сколько критично сайту не падать и не иметь проблем. От бизнеса сильно зависит. Если это визитка и нужна в рабочее время вашего региона, то смысла ноль.
Но есть сервисы (особенно всякие аукционы), где даже 20 минут проблем могут навредить всему бизнесу в целом. Интернет-магазинам это так же важно.
Даже если магазин совсем небольшой. Часто падает - и можно забыть про раскрутку. Так что, вопрос тут не денег совсем.
Кстати, большинство клиентов с одним сервером. Это так, для статистики.
Первоначальной настройки достаточно, если сайт не развивается активно (требуются новые версии программ, увеличивается посещаемость ресурса, дорабатывается код и нужны дополнительные настройки). Тут да, какое-то время проработает без проблем. Да и то, без слежения за резервным копированием, может быть поздно писать админу, когда полетел жёсткий диск, а бэкапы уже месяц как не делаются. Любая система резервного копирования может дать сбой, который вовремя не увидеть.
Это не считая регулярных обновлений программ. Только недавно была уязвимость, которая могла привести к фатальным последствиям.
Конечно, вы можете самостоятельно за всем этим следить. И это может иметь смысл при недостатке средств. В противном случае владельцу эффективнее заниматься развитием, а не слежением за сервером.---------- Добавлено 18.03.2017 в 23:28 ----------Здесь реклама запрещена.
Если интересно, могу в личке рассказать, что требуется серверу для того, чтобы не иметь проблем. Там список очень внушительный.
Это как с бэкапами. Они могут потребоваться раз в год, но этого раза будет достаточно, чтобы нанести непоправимый урон бизнесу, если с ними возникла проблема.
Хотя тоже, можно раз обратиться за настройкой и какое-то время точно всё будет работать. Можно периодически просить проверить за небольшую плату.
Но тут всегда баланс между деньгами и риском. Решать каждому, что в данный момент критичнее.
У крупных компаний со своим it-отделом, есть отдельные специалисты, которые проверяют бэкапы (распаковывают, сравнивают и т.п.)
Администрирование точно так же, как и с бэкапами.
Сначала люди не заморачиваются, потом обращаются разово, а в итоге понимают необходимость в нём.
Нужно за сервером следить 24x7, за теми же бэкапами, производить обновления и т.п.
А то бывает, что клиент со старой ОС приходит, а там уже и обновлять страшно)
Это только в том случае, если сайты будут на работающем ip.
Что очень вряд ли.
Кроме того, внешние подключения сервер будет делать через основной шлюз, если не настраивать отдельно.
Поэтому согласен, для VPS в этом нет смысла (если почта не на других серверах и её работоспособность нужна отдельно от сайта)
Если про уязвимость, то речь о ядре, а не конкретном дистрибутиве.
Нет модуля, который мало кому нужен, нет и проблемы.
А если человеку он требуется, то и без наших инструкций знает, что делать.
Это не говоря о том, что исправления сейчас нет для всех дистрибутивов. А время лучше не тянуть.
В ядре Linux выявлена уязвимость (CVE-2017-6074), позволяющая непривилегированному локальному пользователю выполнить код с правами root.
Проявляется во всех ядрах с поддержкой DCCP, начиная с 2.6.14 и вплоть до выпуска 4.9.11, собранных с опцией CONFIG_IP_DCCP
В большинстве случаев dccp отключен в ядре или подключается как модуль. Его запуск необходимо запретить в системе.
Проверить и исправить можно так:
1) lsmod | grep dccp
Если команда ничего не выдаёт, то модуль не используется и переходим к пункту два. Если модуль найден, попробуйте его отключить через rmmod dccp. Если после этого lsmod | grep dccp ничего не выдаёт, то переходим в пункту два. Если выгрузить модуль не получается, то решение одно - нужно обновлять ядро.
2) Пробуем загрузить модуль через modprobe dccp
Если не загружается и по lsmod | grep dccp ничего не находит, то его нет в системе и уязвимость не коснулась вашего сервера.
3) Отключаем модуль и блокируем его загрузку:
rmmod dccp
echo install dccp /bin/false > /etc/modprobe.d/blacklist.conf
После этих операций команда modprobe dccp должна выдавать ошибку.
Клиентам на тарифе "Базовое" можем бесплатно помочь решить проблему. Для этого вам необходимо создать тикет в отдел "администрирование".
Для клиентов на тарифах "Оптима" и "Премиум" администраторы сделают исправления самостоятельно в рамках еженедельного аудита.
Для клиентов без пакета обслуживания стоимость решения нашими силами - 450 рублей.
Желаем вам успешной и, главное, безопасной работы!
Уважаемые клиенты!
Для улучшения качества связи мы были вынуждены сменить наши номера телефонов.
Сейчас мы доступны по следующим номерам:
Москва: (495) 369-07-24
Санкт-Петербург: (812) 244-45-29
Бесплатный номер для всей России: 8(800)100-38-03
Всё просто.
Настройки должны быть такими, чтобы обслсужить нужное количество клиентов и не выше, чем доступно памяти на сервере (естественно за вычетом на систему и другие сервисы)
А то насмотрелись на настройки mysql, где max connections = 1000 и буфферы по 3Mb. Не удивительно, что сервер падает по памяти, когда её требуется свыше 400% от присутствующей.
И в apache не редко вижу такие значения, что волосы дыбом встают.
На VDS за 10$ пытаются max clients поставить 300-500.
Это механизм идентификации посетителя. К примеру, чтобы сайт понимал, что вы на нём авторизовались под таким-то ником и больше не просил указать логин/пароль.
Подробнее здесь: http://phpfaq.ru/sessions
Лучше настроить автоочистку, а не отключать. Подробно описано здесь http://forum.ispsystem.ru/showthread.php?7409-Проблема-с-удалением-сессий&p=66279&viewfull=1#post66279
