Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.

Определяем доступную память и активность swap.

Перед началом оптимизации давайте взглянем на количество используемой памяти. Для этого необходимо выполнить следующую команду:

$ free -m

Для того. чтобы посмотреть список запущенных процессов и отсортировать их по использованию памяти, необходимо выполнить вот такую команду:

$ ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | less

Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы

Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется "sysv-rc-conf" и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:

Здесь представлен список сервисов, которые я изменил.

• Postfix. Этот сервис позволяет отправлять и получать почтовые email сообщения для домена. Я использую для этих целей Google Apps для отправки почты и mailchimp для новостных подписчиков. Таким образом я остановил и отключил этот сервис.
• Bind9. Он нужен для управления DNS записями Вашего домена. Его можно отключить, так как все DNS записи хранятся у хостера.
• SSHD. Имеются и другие реализации, которые используют гораздо меньше памяти, но они не поддерживают sftp, поэтому данный сервис я оставил без изменений.

Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.

У современных процессоров архитектуры Core i7 существует очевидный, документированный, но отчего-то не очень известный даже среди многих специалистов сценарий priority inversion. Его я опишу в этом посте. В нем есть код на С, три диаграммы, и некоторые подробности работы кэшей в процессорах архитектуры Core i7. Никаких покровов не срывается, вся информация давно общедоступна.

Priority inversion – ситуация, когда низкоприоритетный процесс может блокировать или замедлять высокоприоритетный. Обычно имеется в виду очередность доступа к исполнению на ядре для высокоприоритетного кода относительно низкоприоритетного. С этим должно неплохо справляться ядро ОС. Однако помимо вычислительных ядер, которые несложно распределять посредством affinity и MSI-X, в процессоре есть ресурсы, общие для всех задач – контроллер памяти, QPI, общий кэш третьего уровня, PCIe устройства. В вопросы PCIe я углубляться не буду, т.к. не являюсь экспертом в данной теме. Priority inversion на почве доступа к памяти и QPI я давно не наблюдал – пропускной способности современного многоканального контроллера как правило хватает и высокоприоритетным, и низкоприоритетным задачам. Остановлюсь на кэшах.

Уважаемые коллеги,
особенно топ-менеджеры и владельцы IT-компаний, достаточно частым (если не абсолютно обыденным) является положение дел, когда в компании, занимающейся изготовлением софта, само ПО не проходит никакую процедуру регистрации.

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

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

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

В отсутствие регистрации это достаточно непростой процесс.

Забегая вперед скажу, что фиксировать права компании нужно целым комплектом документов.

В этой статье я расскажу о том, как загруженность шины данных влияет на масштабируемость (scalability) приложений. Под масштабируемостью мы будем понимать не только способность многопоточного приложения сокращать свое время выполнения по мере увеличения числа потоков. Мы также добавим сюда и способность однопоточного приложения, запущенного одновременно в несколько копий (instances), выполняться за тот же самый промежуток времени, что и одна копия. Хотя последний пример было бы правильнее охарактеризовать таким свойством как пропускная способность (throughput), так как он относится к «серверному» режиму запуска приложений. Т.е. это такой режим, при котором на сервере запускается однопоточное приложение, каждый раз когда к нему подключается новый клиент. Главная задача при разработке таких приложений — это снижение их зависимости от общих ресурсов, одним из которых может являться шина данных.