zuborg

Aten-ы в целом неплохие, хотя есть свои ньюансы. Я бы рекомендовал рассмотреть вариант 1-но портовый IP-KVM + 8-ми портовый не IP-KVM, например Aten+Minicom.

Ещё отличный вариант — собственно IPMI, но это не KVM и требует дополнительной настройки. Зато скорость и возможности самые максимальные.

Размер потерь на место — это приблизительно 1/2 * размер блока (для некоторых FS — фрагмента блока, как в UFS) * кол-во файлов (+папок) + оверхед FS * кол-во блоков.
Исходя из первого слагаемого — блоки надо делать как можно меньше, а из второго — как можно больше (тогда блоков будет меньше).
Первое слагаемое можно оценить непосредственно (`df -i` в помощь), второе — оценить, сравнив полное место согласно выводу команды df с собствено размером диска (раздела), обычно разница порядка несколько процентов. В идеале оба слагаемых должны быть приблизительно равны.

Если флешка с фотоаппарата, и файлы — jpg-и, то эффективнее будет пользоваться специальными программами, которые ищут jpeg-сигнатуры. Когда-то мне помогли восстановить несколько фотографий дополнительно…

Как вариант решения — поставьте перед апачем веб-акселератор, который в состоянии принять такой запрос, и дальше форварднет его апачу с этим хидером. Конкретную проксю указать не могу — не сталкивался с такой проблемой, надо пробовать. Возможно nginx, haproxy, varnish, squid…

Тут сложно сказать однозначно, есть разные взаимокомпенсирующие эффекты.
С одной стороны, можно избавиться от ненужного больше поля с флагом — это плюс, с другой — придется добавить индекс по полю с таймстампом, которое занимает уже не один байт, как предыдущее — это минус (индекс будет большое занимать памяти). Сами индексы будут работать одинаково эффективно для указаной выборки.

Я бы на Вашем месте создал бы тестовую табличку и сделал бы бенчмарк, заодно по результатам можно и статью на хабр отписать, многим было бы интересно.

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

Надо тестить, в общем…

Пропишите проксирование на tcp-сокет (а не на unix-сокет) и посмотрите сниффером трафик, будете точно знать какой запрос шлет nginx и какой ответ возвращает php:
tcpdump -nAs 20000 -i lo0 tcp port 9000

Alias /img/ /home/user/domain.com/img/
AliasMatch / /home/user/domain.com/index.html

а так меньше нагрузки на апач будет, без mod_rewrite

Мерцающая подсветка да, напрягает сильно. Также сильная неравномерность цветов в зависимости от угла зрения приводит к эффекту металлического блеска — глаза от этого тоже перенапрягаются.
Ещё есть ньюанс — у человека разрешающая способность зрения по горизонтали больше чем по вертикали — поэтому горизонтальное расположение субпикселов в ряд более предпочтительно для сглаживания — увеличивается горизонтальное разрешение шрифтов.

Но мониторы мониторами, а не стоит забывать и про прочие факторы:
— Внешнее освещение. Окружение по яркости должно быть близким к яркости монитора. Работа в темной комнате за любым самым прекрасным монитором эффективно посадит глаза в краткий срок.
— Шрифты. Маленькие шрифты не менее эффективно садят глаза. Отсутствие сглаживания приводит к увеличению высокочастотной составляющей (из-за резких границ пикселов) — тоже дополнительная нагрузка. Некачественно сглаживание тоже приводит к лишнему напряжению глаз.
— Расстояние и местоположение монитора. Высоко расположенный монитор не позволяет расслабиться глазам при нормальном положении шеи. Слишком близко расположенный монитор требует усиленной аккомодации хрусталика, что впоследствии может привести к фиксации такого состоянии и неспособности фокусироваться на бесконечность (близорукость).

1. 30К человек одновременно? один сервер навряд ли потянет, скорее всего придется строить классический кластер: фронтенды для балансировки -> бекенды для обработки < — дб и кеширующие сервера
Заранее что-то сложно сказать, для начала можно запустить на одном сервере на небольшом трафике и дальше масштабировать самые загруженные елементы.

2. поближе к основной аудитории

4. все равно живой трафик будет определять реальные проблемы архитектуры, запускайте потихоньку

Используются, конечно, если условие where это позволяет.

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

Даже при инсерте для проверки уникальности значения поля нужен индекс.

1. используйте verbose режим в ssh, например коннектесь с unix-сервера или с самой убунты на себя же (залогинившись как slave):
# ssh -v master@1.2.3.4
2. смотрите логи в /var/log/ особенно auth.log, security.log, messages.log
3. просмотрите содержимое ~master/.ssh/ возможно там кроме ключей какие-то нестандартные конфиги или rc-скрипты.
4. просмотрите /etc/ssh/, возможно что-то обнаружите в sshd_config или возможно там есть sshrc скрипт

Для первого запроса надо два индекса, начинающиеся с name_last и name_first соотв. Т.к. используется OR — одного составного индекса будет недостаточно.

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

Итого, для обоих запросов надо два индекса — один составной из обоих полей, второй — из одного поля, которым заканчивается первый индекс:

CREATE INDEX idx1 ON doctors (name_first, name_last)
CREATE INDEX idx2 ON doctors (name_last)

smartctl для определения состояния диска.

Также есть смысл прогнать быстрый тест скорости, для диагностики проблем с механикой. Для FreeBSD это `diskinfo -t`, для остальных можно банальный `time dd if=/dev/sda of=/dev/null bs=1m count=100 skip=1000000` скриптом пару раз в разных местах диска дернуть, либо бенчмарк какой-то. Для дохлого винта будут большие задержки.

Ну и полный тест поверхности, в т.ч. на запись, типа `badblocks -v -w -s -b 4096 /dev/sda`. Для терового винта займет с полсуток-сутки, т.к. требуется 4 прохода на запись + 4 на чтение.

Строго говоря, ответ «snmp» просто меняет протокол доступа к информации с ssh на более простой и пригодный для большого кол-ва машин.

Но вообще для массового мониторинга все равно надо либо опрашивать все сервера (через ssh, snmp, http, свой вариант), либо настроить чтобы сервера сами отсылали уведомления на центральный сервер (syslog, mail, опять же ssh, http, snmpv3 или что-то свое).

Вариантов много, у каждого свои преимущества и недостатки. Например, опрашивать сервера по snmp и строить rrd на одном сервере очень удобно и нормально когда их меньше сотни, а на тысячу серверов одного центрального будет не достаточно (либо он должен быть действительно мощным, особенно касательно скорости дисков).

Так обьектный файл как раз машинный код и содержит, и его размер таки меньше получился.

Надо смотреть на опции сборки, активирован ли дебаг режим, сделан ли strip…

Согласен с foxmuldercp, замечу только, что если вопрос только в разделении настроек php (включая модули), то можно обойтись и без виртуализации вообще.

Все равно на каждую вирт.машину понадобится отдельный ип — можно на этот ип поцепить отдельно скомпилированный апач+пхп+остальное. Отдельно скомпилированный — в смысле в свою личную изолированную директорию (./configure --prefix=path ..), со своими модулями и личными .ini/.conf файлами.

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

# grep -Rh '#include'. | sort | uniq -c | sort -n
Всякие библиотеки требуют соотв строчки #include чтобы импортировать функции, константы, макросы и прочее от библиотеки.

Узнать откуда ставить соотв .h файл зависит от ОС, возможно поможет whereis или locate. Ну или гугл.

Согласно теореме Геделя о неполноте, существуют желания, которые сбываются, но в тоже время это невозможно установить в рамках исходной формальной системы (т.е. не рассматривая само желание в комплексе формальной системы).

P.S. Подобных рекурсивных утверждений куча.

1. для логирования по сети стоит использовать udp а не tcp, т.к. мелкий затык может сложить логирование вообще.
2. возможно, стоит рассмотреть вариант собирать логи таки локально, но не внутри каждого вдс, а в dom0, передавая их по сети (но не выпуская траф за пределы машины). Это поможет более эффективно кешировать запись логов средствами фс dom0 и снизить io.
3. значительная часть логов генерится мелкими запросами на картинки, их можно выборочно отключить, оставив важные логи на запросы к скриптам

jpegoptim и pngcrush
первый умеет перезаписывать файлы если удалось оптимизировать, для png надо обертку писать.
Файлы же проще всего искать find-ом, например, только свежие, и направлять на обработку через xargs.