у меня чуть похожий вариант, bash функция
function sr_monitor92 { watch -n ${1:-5} "psql -h 127.0.0.1 -U postgres -c 'select pid,usesysid,application_name,client_addr,backend_start,state,sent_location,write_location,replay_location,sync_state,pg_xlog_location_diff(sent_location, replay_location) as bytes from pg_stat_replication order by 5'"; }
>> Лишних серваков не бывает.. Какой посоветуйте ?
Не совсем понял, мы все еще про VPS или про железные сервера? ))
В обоих случаях, когда бюджет ограничен, можно рассматривать недорогие Supermicro. Еще мы в свое время брали недорогие самосборы на платформе Intel у team.ru - очень хорошие воспоминания о качестве железа - как никак Intel. (если речь про VPS то недорогие тарифные планы).
Статистика же собирается через мониторинг, тут полно решений, из моих предпочтений это NewRelic (плюс Zabbix когда серверов больше пяти). Они собирают данные по нагрузке (cpu, memory, diskio, tps, rpm и проч.), ну полученные данные рисуются в виде графиков - отслеживайте рост нагрузки и планируйте развитие инфраструктуры.
Дык, vps подходит на начальной стадии пока нет оценки как вы будете утилизировать ресурсы. когда у вас есть vps вы не ограничены рамками уже купленного hardware, вы только у хостера добавляете себе ресурсы, выделяете новые машины (и не возникает мысли, блин мы купили этот сервер, а надо было чуть другой конфигурации, ыы!!!).
Поработав на vps , оценив нагрзуку/посещаемость уже можно более точно оценить потребности в оборудовании. И если уж хостер не устраивает по цене/ресурсам уже планировать миграцию на собственные сервера в ДЦ.
Да и в случае если проект не взлетит, у вас не будет головняков, куда девать купленный сервер.
Да, речь про архитектуру проекта вцелом.
В вашем случае, можно взять 2-сокетную материнку с 1 процом (+1 сокет останется на вырост). Тормозить не будет лишь в случае если вы не запустите одновременно работающих php процессов больше чем доступных ядер))). И модели процессоров должны быть одинаковые.
По объему памяти смотрите на количество каналов у процессора. По кол-ву каналов, ставьте такое же кол-во планок. Это не принципиально, но связка память+проц будут работать эффективнее.
В итоге если e5-2620, то это 6 ядер (12 потоков c HT), 1 поток на nginx, 1 поток на на memcache, 9 потоков на php+postgres, 1 поток на pgbouncer. Маловероятно что все потоки будут работать одновременно, так что должно всем хватить. Со временем если упретесь в производительность по процам, докупите еще проц или уж сразу сервер и сселите на него либо базу, либо приложение+кэш. По памяти, смотрите на объем потребляемой памяти и докупайте при необходимости. Ну и по дискам тоже можно много сказать, берите только SAS нынче они недороги, например это: www.nix.ru/autocatalog/hdd_ibm_hitachi/HDD_SAS_2.0...
Что то много всего получилось =) Вобщем спрашивайте, если что.
теория это хорошо, определитесь в какой СУБД вы хотите шарить, и читайте доки по ней. Так вы будете разбираться в вопросе выбранной СУБД, и ответы на частные общетеоретические вопросы найдете по мере изучения этой документации.
посмотрел ваш конфиг, у вас там
fsync = off
synchronous_commit = off
это конечно увеличивает скорость, но дает риск коррупции данных (1) и риск потери закоммиченных транзакций (2) в случае отказа по питанию. на критичных сервисах это совершенно недопустимо.
может и фигня, если бы был уверен то не писал бы в Q&A ))
вариант с cloudfront тоже не весть какой фонтан, основные площадки раскиданы по миру непонятно какие задержки будут при отдаче (в той же статье 372ms)
>> 1) Почему s3fs? Используйте родное API.
можно поподробнее в чем преимущества родного API (вообще вцелом, не сравнивая с s3fs)
>> 2) Кто последний, тот и папа. Насколько я знаю, блокировок нет, это тупое хранилище.
блин, фигово
>> 3) Зачем лишнее звено в виде «pagecache/nginx/etc»? Отдавайте прямо с s3.
не совсем понял, т.е. в страницах сразу подставлять амазоновские урлы?
>> Вы пользуетесь CMS,
нет, это не CMS но там есть команда разработчиков (интересно может есть гемы реализующие работу с S3? )
>> Вы уверены, что Вам нужно использовать какого-то другого CDN провайдера?
да, там основная аудитория Россия и ближнее зарубежье (UA, BY, KZ), сейчас все раздается через Ngenix и раздается достаточно быстро, не хотелось бы в новом решении потерять скорость отдачи.
1. я правильно понимаю что мы снимаем iostat -x с опеределенным интервалом? Если да, то как потом анализировать эти данные, считать среднюю? или вобще лучше завести в заббикс…
2. Уверены? ведь pgbench создает всего 4 таблицы и потом работает с ними на протяжении всего теста, не слишком много получится файлов.
3. тогда обычные логи придется писать еще на отдельный том =))
а чем не угодил initramfs?
если хотите чтобы образ грузился без приминения initramfs, выкиньте из системы сопутствущие модули (mdraid, lvm например) initramfs зачастую используется чтобы загрузить корневую фс с рэйда или lvm. В случае например gentoo это можно сделать, но вот для rhel я чтото неуверен что сходу получится.
1099511627776
да в таком случае хороший универсальный вариант сложно придумать… в голову приходит разная экзотика связання с OCR и дальнейшим анализом… но такая задача уже может вылиться в совсем нескучную, наоборот даже интересную деятельность:)
Первое задание таки можно (полу)автоматизировать. Открыть файл, прочитать заголовок и по нему оформить имя файла.
Или например по каждому файлу собрать список самых встречающихся слов, дальше програмист смотрит список, сам придумывает имена и дальше скриптом переименовывает все 12000 файлов.
