Это просто неизбежное зло, т.к. на шаред хостингах было не дать иной доступ к базе. Собственно, только по этому он так распространён.
А так, там не раз были дыры, например. Ну и в принципе, это широко открытая дверь, если стащить пароль от базы - даже бекдор заливать не надо...
Ну и исполнение каких-то сервисных операций с базой в контексте веб сервера это очень плохая мысль.

Дорогая по использованию ресурсов. Страничку без счётчика можно отдать из кеша целиком готовую, в большинстве случаев... Страничка просмотры которой считаются, вызывает полный бутстрап друпала, запросы к базе и.т.п.

Если по какой-то причине, статистика посещений внутри сайта вам не критически важна, её просто стоит убрать совсем.

Довольно странный вопрос - либо вам надо хранить эту информацию, либо нет. Природу не обманешь, и если просмотров много данные о них будут занимать много места.

По поводу OPTIMIZE TABLE: это функция во-первых, работает только для myisam таблиц, а во-вторых не уменьшает количество данных, а "дефрагментирует" таблицу, для более шустрого к ним доступа.

Вообще, обычно, все эти счётчики просмотров, совершенно не нужная рюшечка, особенно внутри сайта. К тому же очень "дорогая".

По upd, никаких проблем с этим нет - проверено лично.
Мне, например, вообще всё равно, какая у меня хост система из win|lin|mac. Что phpstorm, что virtualbox, что ssh работает а них всех.

1. И это вам чем-то мешает? через какое-то время, вы забываете про него и он становится уже совсем не актуальным и с не закрытыми дыами, в отличии от обновляемого регулярно из репозиториев. Если пользуетесь пакетным дистрибутивом, надо пользоваться для установки пакетным менеджером, иначе, система быренько превращается в помойку.

Сomposer есть в репозиториях ubuntu 16.04, и лучше оттуда его и ставить. Хотя приведённый способ рабочий.

Зачем вам apache + php-fpm, с чего бы это предпочтительно? Если уж у вас на фронте апач, то лучше использовать mod_php* - это меньшие накладные расходы.

«т.к. используем сервер для своей разработки то меняем владельца папки www для удобства работы:»
Так а что мешает просто в своей домашней папке разрабатывать - сайты совершенно не обязаны лежать в /var/www на самом деле...

Сервер может уйти в свап, если максимальное кол-во процессов не верно почситано, может начать работать oom, прибивая процессы, но на один процесс предел выделения будет всё равно неизменен. Вне зависимости от виртуализации общего кол-ва памяти и.т.п. Т.е. при таких проблемах будут совсем другие ошибки - отсутствие ответа, http 500, адские тормоза, но не «Fatal error: Allowed memory size of *** bytes exhausted »

Вообще говоря, да, 128МБ вполне может не хватать Drupal, особенно, если сайт сделан не очень продумано, и используются всякие панели, DS и.т.п. От посещаемости зависеть потребление памяти на генерацию страницы, в общем-то не должно, если конечно, на ней не показывается какой-нибудь лог последних посещений. Или какой-нибудь уж очень плохо сделанный счётчик онлайн пользователей.

Ничего подобного! Это ограничение на память одного процесса, оно не зависит от того, сколько пришло клиентов, и не делится между обработкой разных запросов.

Это совершенно бесполезная изначально защита, достаточно открыть этот pdf не в acrobat, и он будет прекрасно копироваться. Ну и вообще, надо понимать, что если вы что-то опубликовали, это может быть скопировано массой технических средств, или даже тупо вручную перепечатано...

Если вы не хотите распространения информации, не показывайте её, или не показывайте всем.

Зачем искать (ну или делать) какой-то готовый механизм, который должен будет учитывать 100500 случаев, и который заменяет 2-3-4 строки кода?
variable_set/variable_get позволяют сохранять/получать переменные. Как получать/сравнивать таймстампы, думаю не стоит объяснять?

С помощью таких инструментов можно делать выводы лучше/хуже стало работать при каких-то изменениях.
Ничего просто замер времени ответа, о качестве работы, или тем более качестве настройки vps не скажет.

1. Очередная огромная глупость в исполнении tlito. Это просто ничего не даст. Это отдельные фрагментарные знания, которые вообще никак не помогут настроить сервер в итоге...

По первым 4 пунктам:
1. На это нужны годы, без шуток.
2. Если в вас большой серьёзный проект, и нужна своя инфраструктура, тут у вас других вариантов просто нет. Если вы влезаете в какой-нибудь хостинг - то п.4 воспользуйтесь им, будет дешевле.

Альтернатив PhpMyadmin вполне есть, например Mysql workbench или HeidiSQL. Которые не имеют при том проблем с объёмом данных или временем выполнения запросов, т.к. выполняются не в контексте веб сервера.

Всё описано в документации - выбирайте, читайте, ставьте: https://www.drupal.org/documentation

Эту команду надо запускать из поддериктории core/ в корне сайта, а не из самого корня сайта.

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

А-ха-ха. Отлично, этой я ещё не видел.

Выше есть этот запрос.

Я вас очень разочарую. То, что у хостера есть пресет для установки какой-то CMS, вообще ничего не говорит о том, что в дальнейшем сайт на этой CMS, будет хорошо у этого хостера работать. Мало того, это даже не говорит о том, что выделяется достаточно ресурсов для среднего сайта на этой CMS. Да вообще, ни о чём это не говорит. Это просто фишечка в панели хостера, которая очень просто делается, и никому в общем-то не нужна.

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

Если вы найдёте хороший виртуальный хостинг с PHP 7+, достаточным, для ваших проектов, ограничением памяти процесса PHP, и без глупых ограничений на количество запросов Mysql, это будет для вас в итоге оптимальный вариант. С одной стороны, это будет дешевле остальных вариантов, с другой стороны вам не надо будет думать о инфраструктуре.

«Вопрос apache 2.2. или apache 2.4. Принципаильно?»
Нет, не важно, вообще может даже его не быть. Берите, какой будет.

«Если есть возможность поставить php выше 5,6, какую выбрать?»
Для Drupal 8 разумно выбрать PHP 7+.

Обычный VPS/VDS/сервер с вашими знаниями брать не разумно. Даже если и заставите работать изнасиловав мозг техподдержке, и задав 100500 вопросов на форуме, будет плохо, и в плане работы, и в плане безопасности.

Да, конечно, спасибо - поправил.

UPDATE users SET `status` = 1 WHERE uid = 1;
Если это админский аккаунт с uid =1, и не применяется префикс таблиц.