gaelpa

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

Сериализуйте объекты в инициализированном состоянии и только восстонавливайте их при каждом запросе.
Подключения к базам и прочее, делайте по мэджик методу __wakeup (или __set_state если используете var_export).
Причем большинство "подключений к базе" не потребует дополнительной работы за счет сохранения состояния между запросами на уровне расширения.
Ну и не забудьте сделать профилирование, а то может спички оптимизируете на самом деле.

Монга использует mmap и соотв. не позволяет работать с базами >2Gb на 32-битных системах.
Для нормальной работы требуется 64-битная платформа, ос и сама монга.
Если у вас есть только x32 и не-крошечная база, то монга просто не для вас.

Можно почитать man find.

Включите временно логи доступа и твитните статью сами.
Может твиттер пытается сделать превьюшку ссылки и нечаянно наступает на какую-то вашу «ахиллесову пяту» вроде циклического редиректа или чего-то подобного. Логи должны пролить свет на что именно.

Бумбурум косвенно уже отвечал на этот вопрос habrahabr.ru/company/mailru/blog/198702/#comment_6891024

Можно написать локальный (в своей сети) прокси под ваш протокол и перенаправлять трафик на него через подмену локальной ДНС-записи.
При таком варианте вам все карты в руки по подмене данных + можно «перехватывать» SSL трафик (у вас же есть ваш сертификат).
Минусы — нужно заморочиться.

chroot это chroot и к правам доступа отношения не имеет. Равно как и chdir (это cd в шелле).
Вас интересуют параметры user = и group = и установка соответствующих прав на папки в которые собираетесь писать.

Rsync и scp будут грузить процессоры устройств шифрованием, я бы посмотрел на консольные утилиты (или, как выше предложили, графические если есть) для работы с более шустрыми протоколами: nfs, samba, ftp.

RabbitMQ / какой другой AMQP сервер?

Мало информации.
Посмотрите логи php-fpm,
включите логи nginx, какие там ошибки,
посмотрите какие процессы находятся в состоянии D в выводе «ps axfu», какая вообще загрузка и какими процессами,
посмотрите, нет ли у вас стопки выполняющихся запросов в mysql (предположил по-умолчанию).

Навскидку, возможно это переполнение пула php-fpm вызванное заторами в скриптах (может тяжелые запросы к базам или даже ошибка базы).

В довесок мой не слишком удачный опыт с выбором NAS.
Кончина sata контроллера в десктопе освободила пару терабайтников, на которых не хватило портов второго контроллера. Для них решил взять отдельую коробку с заделом на «поковыряться» и критерием «недорого».
Остановился на Netgear readynas nv+ rnd4000 v2 на 4 слота. Брал за что-то вроде порядка 8-9к.
Уже в процессе эксплуатации выяснил почему так недорого: запись в рейд по сети вытягивает где-то около 25МБ/с (в десктопе диски тянут порядка 80), машинка на нешустром арме с вшитыми 256МБ оперативы (в отличие от её брата-предшественника не имеет SO-DIMM слота расширения).
С встроенными/загружаемыми приложениями у арм-линейки readynas всё тоже не слишком радужно.
Зато линукс на базе дебиан под капотом.
Т.е. можно пользоваться как не слишком шустрым хранилищем и хостить внутри нересурсоемкие приложения, но разгуляться не получится.

Если нет нужды в хранении большого объема данных и обеспечении их безопасности зеркалированием, то нетбук — оптимальный вариант.
НАСы с хорошими процами и запасом оперативы стоят заметно дороже нетбуков (даже новых). [Если я в этом не прав, ткните ссылкой — обновлю домашний парк]
Но больших объемов данных и какого-никакого raid1 на нетбуке вы уже очевидно не построете.

Есть dklab realsync который предназначен как-раз для автоматического одностороннего «rsync'a».
Правда он хочет ssh на той стороне. Ну и с разграничением прав слету неясно как разобраться.
Основное назначение — синхронизация кода по направлению к дебаг-окружению.

Посмотрите, например, wiresharkом на сетевой обмен с вк при работе из браузера и из QT приложения. Наверняка там случается какой-нибудь редирект на какой-нибудь https всвязи, например, с отсутствием нужных кук при запросе из qt.

А reload (SIGUSR2) в вашем случае не достаточно?
>> graceful reload of all workers + reload of fpm conf/binary