Где купить самый большой список open proxy?

Как вариант, покупать списки сразу с нескольких ресурсов. С ботнетами конечно сложнее. Пока в 99% случаев при обнаружении попыток проникновения я в ручном режиме брал IP, с которых шли атаки, и в google вбивал "IP open proxy" И всегда вылезал какой-нибудь список проксей, где этот ip числился.

Почему у MongoDB сильно варьируется время ответа?

Да, без индекса там на минуты идет время. Это не вариант.

Почему у MongoDB сильно варьируется время ответа?

У нас пишется постоянно. А тормозит периодически. Больше похоже на перестройку индекса?

Где хранить домашний фотоархив?

Sergey Lerg: Не удобно то, что нужно у папок галки тыкать. Забыл ткнуть, удалил на диске - в облаке удалится. Нужно быть внимательным - это не "для домохозяек". Жена не поймет такого "сервиса".

Где хранить домашний фотоархив?

Разве Google Drive и облако Mail.ru работают не по принципу Dropbox? Нужно же копию у себя на локале хранить? Или нет и я просто не умею ими пользоваться?

Где хранить домашний фотоархив?

Sergey Lerg: Сейчас около 40 гигов.

Что покрутить в настройках MongoDB или самой ОС, чтобы быть готовым к всплеску инсертов?

Ну SSD еще куда ни шло. А без журналирования страшновато.

Есть ли подобная программа для android?

Если что, автор приложения не я и не имею к нему никакого отношения. У меня тоже на 4-й нексус не ставится с Google Play. По ссылке на 4pda можно скачать APK файл и установить напрямую. У меня запустилось. Но проверить в бою еще не было возможности :)

Как правильно построить отказоустойчивый кластер memcached для хранения сессий PHP?

В первой статье есть соответствующий абзац:

«Совсем не должны терять». Memcached удобен для хранения сессий пользователей – все сессии равнодоступны со всех серверов, входящих в кластер frontend’ов. Так вот содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно дублировать ключи сессий на нескольких серверах memcached из кластера, так вероятность потери снижается.

Вот я и хочу дублировать ключи сессий на нескольких серверах memcached из кластера…
Но в статье не рассказано, как это правильно делать?
Как вариант — это написать свой session handler и все сессии писать на все доступные memcached сервера.
Хорошо, запишем.
Но я совершенно забыл о дальнейшей судьбе сессий — с какого севера их читать? Если часть memcached будет недоступна, то нужно автоматически выбирать доступный. Т.е. нужен как-нибудь балансировщик. Тут вроде проще, haproxy или nginx должны помочь.

А теперь подумаем дальше. Если сессии мы пишем на все memcached сервера, но если один из них на время выйдет из игры, то он будет рассинхронизирован по отношению к остальным. Т.о. очередной вопрос — как его снова полностью синхронизировать с остальными?

Резервирование канала интернет для сайта с статическим IP

Личный опыт говорит о том, что за 5 минут переключается в лучшем случае 50% :( Переключалось бы 99% — проблем бы было меньше и городить разные решения не пришлось бы.

Резервирование канала интернет для сайта с статическим IP

nginx.org/ru/docs/http/ngx_http_upstream_module.html
max_fails=число
задаёт число неудачных попыток работы с сервером в течение времени, заданного параметром fail_timeout, после которого он считается неработающим, также в течение времени заданного параметром fail_timeout. По умолчанию число попыток устанавливается равным 1. Нулевое значение запрещает учёт попыток. Что считается неудачной попыткой, задаётся директивами proxy_next_upstream, fastcgi_next_upstream и memcached_next_upstream. Состояния http_403, http_404 и not_found не считаются неудачными попытками.

Т.е. если connection timeout и т.п. вылезает, то nginx начинает обращаться по другому IP (резервному).
Это только один из сценариев.
Можно оба канала использовать на постоянной основе и при сбое одного весь трафик на второй перекинуть.
Можно вообще не nginx, а haproxy использовать — там больше возможностей по настройке определения жив канал или нет.

Т.е. я хочу сказать, что тему с балансировщиком можно развивать дальше. Какой из них выбрать — это уже тонкости, не влияющие на архитектуру.

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

1. «Это самое плохое решение» — с чего вы взяли? Пробовали? Читали подобный опыт других? Раз пишите тут, то зачем писать загадками. Дайте, пожалуйста, наводку, на то, где подтверждены ваши экспертные знания.

2. Не понял, как вы меня связали с кем-то из этого поста habrahabr.ru/company/bitrix/blog/179803/? Где битрикс, а где я… Да и в комментах к той статье я никого знакомого не вижу :)

3. Остальная часть вашего коммета снова ни о чем. Голые умозаключения без какой либо конкретики :(

Вы для чего коммент написали? Скучно было?

Сорри, если грубо, просто выглядит ваш текст бредово. Ничего личного. (с) EugeneOZ

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

Версия интересная, но не очень правдоподобная. Так как в iSCSI количество сессий между сервером и хранилищем равно количеству путей — их у нас 8, все остальное обрабатывается на уровне мультипасинг демона и драйвера файловой системы.

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

> все PHP процессы на обоих серверах встают на ожидании разблокировки сессии
Я хотел донести следующее. От пользователей идут запросы. Скажем от каждого уже пришло по 2-3 запроса. И эти 2-3 процесса ждут разблокировки сессии данного конкретного пользователя. Таких пользователей одновременно сотни. Умножаем 2-3 на сотни и получаем больше 600 на каждом сервере зависших процесса.

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

Я не понимаю, почему файловое хранилище вы называете костылем?
Про нужность блокировок сессий можете вот тут почитать и высказаться в комментариях: habrahabr.ru/company/bitrix/blog/179803/

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

Видимо вы что-то не так поняли или я не так выразился. Сессии одного пользователя не блокируют сессии других пользователей.

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

Спасибо за развернутый ответ. Над многими рекомендациями крепко подумаем.
Ситуация такая. Проект старый. Около 7 лет. Постоянно развивается. Ну скажем честно — код не самый элегантный :)
Поэтому, например, вынести что-то критичное в базу — это рефакторинг ядра. А это ой как не хочется делать. Но это наши внутренние проблемы, которые опять же касаются рекомендаций по «переписыванию» проекта.
Обработчик сессий у нас стандартный.
Заблокированных PHP-FPM процессов на каждом PHP сервере оказывается по 600 штук. 600 — это максимальное количество процессов, настроенное в php-fpm.conf и сайт встает :(

Теперь про освобождение сессий. Когда с сессиями на файловом хранилище работает один сервер, то проблем нет. Это значит, что сессии освобождаются. Иначе бы мы имели ту же самую проблему с очередью на разблокирование.
А проблема вылезает именно в момент подключения второго PHP сервера.
Подозреваю, что проблема больше относится к настройке операционки.

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

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

PHP Cluster и файлы сессий на общем файловом хранилище. Возникают бесконечные блокировки?

Вы прочитали мой вопрос? Там ответ на ваш вопрос:
> да, нам жизненно важна блокировка сессий
redis читал, что уж больно тяжеловат. И честно скажу, не в курсе, есть там блокировка или нет. А вы знаете?
А про memcached что-то нет инфы, что там появилась блокировка. Или я ошибаюсь?