Ну вот во время тормозов и смотреть.
Запишите пока типичные цифры загрузки, запишите ещё, сколько PPS (пакетов в секунду) и полоса пропускания используется на интерфейсах - чтобы сразу было с чем сравнивать.
> Но ведь в итоге каждый файл пустой, почему нельзя использовать один для всех?
Для удобства и автозагрузки. Каждому классу свой отдельный файл и по строго-определённому пути.
Пустой - потому что больше ничего и не надо. Достаточно наследуемого интерфейса.
FanatPHP:
> КАКОЙ СМЫСЛ делать quote и потом делать обрезание?
Мимикрировать под поведение экранирования, на которое ориентировано порядком существующего кода.
Чтобы мигрировать на нормальный PDO сразу и затем в спокойном режиме аккуратно заменять запросы на подготовленные.
Читайте исходный вопрос (про что вы очень любите на гране цензуры истерить)
> sql-запросы переписать не смогу, так как их очень много.
Какие технологии-то?
Если домен только зарегистрирован и не проявляет активности - может пройти не один месяц, прежде чем его заметят поисковики. По неосторожно засветившемуся рефереру в метрике/аналитике, случайной ссылке.
Современные технологии - они в хранении этих террабайт данных и быстром и качественном ранжировании по запросу. А сущность краулеров как была так и остались - ходить по всем встреченным ссылкам сети.
Опыт - именно что опыт. Сдохнут ведущие поисковики - на такой огромный спрос моментально вылезут другие. Как о них узнает, об этих новых? Всё так же.
И напомню о таком явлении современности как соцсети. Каков процент людей, которые кроме пары сайтов вообще никуда не ходят? Собственно, сама соцсеть поисковик и запустит.
Читайте историю. Это ведь совсем недавно было, всего-лишь прошлое тысячелетие.
Напрямую от разработчиков и авторов этих сайтов. И дальше по друзьям, знакомым и незнакомым.
Есть, наверное. 2015 год уже почти, как никак. Точно что-то для автоматического реконнекта есть.
Для openvpn гугл подсказывает keepalive, для ssh - мелкий башевый скрипт: stackoverflow.com/questions/6758897/how-to-set-up-...
Дополнительным плюсом такого решения - реплика пойдёт зашифрованная и не будет на мастере торчать открыто в мир.
> можно ускорить процесс как минимум использузуя for
или же замедлить. Двусвязный список обходить по связям быстрее, чем искать ключи. habrahabr.ru/post/216103
И из-за copy-on-write копирования данных не происходит.
И всё это ничего не стоит на фоне network io (http ведь заметили?).
Полностью-укомплектованный классический рейд10 - это минимум 4 диска. (mdadm умеет на 3 дисках, кстати).
Но можно создать изначально деградировавший массив. raid10 - это комбинация raid0 и raid1 (не помню, кто в теории поверх кого, не то страйп на двух парах зеркал, не то зеркало поверх пары страйпов). Raid10 гарантирует выживаемость при смерти любого диска из массива, но помимо этого можно потерять ещё один диск и рейд всё равно останется на плаву - но уже не любой диск массива. Двух из четырёх дисков вполне достаточно для нормального старта массива с ручным указанием, какой диск будет где.
mdadm -v --create /dev/md1 --level=raid10 --raid-devices=4 /dev/sdc missing /dev/sdd missing
ldvldv: кажется, я много чего у lvm пропустил. Может, напишете пост на хабре об опыте использования (если есть, конечно), мониторинге и обслуживании? Какие отличия от более известной связки lvm поверх mdadm? (так понимаю, вы r/o, но такая статья песочницу пройти должна без проблем)
ldvldv: вроде же только страйпы умеет. Или избыточность тоже научился?
DimOFF: lvm или jbod - оба дадут пространство равное совокупной ёмкости всех дисков (диски могут быть разные). Но в случае смерти диска (синоним "расходник") - данные, которые на нём были, будут утеряны. А если поверх только одна большая файловая система - то и другие данные будут повреждены из-за фрагментации. Дешевле считать, что будет потеряно вообще всё.
Рейды с избыточностью переживут подыхание одного расходника и данные не пострадают, но цена - уменьшение доступной ёмкости. (плюс нужны идентичные диски по ёмкости)
raid5 заберёт один диск из массива. Доступна будет суммарная ёмкость только двух дисков из трёх. Медленнее на записи, сожрёт несколько процентов CPU.
raid10 - доступна только половина от суммарной ёмкости дисков. На трёх дисках не скажу, быстрее ли, но CPU фактически не трогает