it

Или как перегнать память из cache во free :)
Зачем вам это надо - думайте сами. Обычно необходимости в сбросе кэша нет, т.к. при нормальном режиме работы система сначала возьмёт память из кэша, прежде чем перейти в swap.

Данная статья предназначена специалистам, которые знают что делают.

Начиная с версии ядра Linux 2.6.16 есть механизм для сброса "page cache" и/или inode и dentry:

Сбросить pagecache
# echo 1 > /proc/sys/vm/drop_caches

Сбросить кэш dentries и inodes
# echo 2 > /proc/sys/vm/drop_caches

Сбросить pagecache, dentries и inodes
# echo 3 > /proc/sys/vm/drop_caches

Эта операция безопасна и очищает только то, что совершенно не используется. "Грязные" объекты не будут затронуты.

Что в IP-адресе тебе моём...

IP-адрес это сетевой адрес узла в компьютерной сети.
Естественно, имеется описание о каждом из узлов. Кое-что из доступного описания может быть полезным.

Устанавливаем telnet-клиент в Windows Vista / 7:
1) Открыть Пуск -> Панель управления -> Программы и компоненты...

Команда найдёт все файлы в текущем каталоге и подкаталогах, содержащие OLD_TEXT и заменит строку "OLD_TEXT" на "NEW_TEXT":
grep -HR OLDTEXT ./ | awk '{print $1}' | sed 's/:.*$//' | grep -v '~' | sort | uniq | xargs perl -i -pe "s/OLD_TEXT/NEW_TEXT/g;"
Учитывайте, что текст указан в выражении, если в вашем OLD_TEXT встречаются спец.символы - их нужно экранировать \
Для работы команды кроме gnu utils нужен perl.

Часто наблюдаю этот вопрос, посему ответ:

504 - значит скрипт (бэкенд) слишком долго отвечал или скрипт завершается раньше, чем получен ответ.
Причин может быть много: недостаток ресурсов (чаще всего - оперативной памяти), кривые скрипты, проблемы с базой данных и файловой системой, кривая настройка сервера...

Обнаружил, что в очень распространённом модуле Lightbox2 устанавливается свойство css z-index в 10500. Примечательно, что это встречается не только у друпаловского лайтбокса.
Интересно, почему не 100500?
Какими-то рекомендациями по css запрещено больше разрядов?
Хотели написать 100500 но ошиблись в одном нуле?

Как-то так:

Логинимся под рутом в MySQL
mysql -uroot -p

Создаём базу:
CREATE DATABASE ;

Добавляем пользователя, задаём пароль и даём права на базу :
GRANT ALL PRIVILEGES ON .* TO 'my_user'@'localhost'
IDENTIFIED BY 'my_password' WITH GRANT OPTION;

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

GRANT ALL PRIVILEGES ON *.* TO 'my_user'@'localhost'
IDENTIFIED BY 'my_password' WITH GRANT OPTION;

Доступ к базе для данного пользователя возможен только с localhost. Если вы хотите дать ему доступ к базе с любого хоста, используете % вместо localhost:

GRANT ALL PRIVILEGES ON .* TO 'my_user'@'%'
IDENTIFIED BY 'my_password' WITH GRANT OPTION;

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

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

ПО сайта представляло собой CMS на PHP, с применением MySQL и Smarty. Первым делом была найдена хостинговая компания, которая имела опыт высоконагруженных проектов. Мы предоставили им свою требуемую конфигурацию:
Балансировка нагрузки (с запасом)
2 веб-сервера
MySQL сервер (с запасом)
машина для разработки

Что мы получили (хостер сказал, что этого будет достаточно):
Балансировка нагрузки — Single core, 1 Гб RAM, Pound
2 веб-сервера — Dual core, 4 Гб RAM, Apache
MySQL сервер — Quad core, 8 Гб RAM
машина для разработки — Single core, 1 Гб RAM

Для синхронизации файлов хостер установил DRBD в конфигурации active-active.

Наконец, время переноса пришло. Рано утром мы переключили домен на новые IP и начали мониторить наши скрипты. Трафик мы получили практически сразу и казалось, что все работает хорошо. Страницы загружались быстро, MySQL обрабатывал кучу запросов и все были счастливы.

Затем неожиданно прозвонил телефон: «Мы не можем зайти на веб-сайт, что происходит?!» Мы посмотрели в наше ПО для мониторинга и увидели, что сервера упали и сайт не работал. Конечно, первым делом мы позвонили хостеру и сказали: «все наши сервера упали. Что происходит?!» Они пообещали проверить сервера и перезвонить после этого. Спустя некоторое время они позвонили: «Ваша файловая система безнадежно испорчена. Что Вы делали?!» Они остановили балансер и и сказали мне посмотреть на один из веб-серверов. Открыв index.php, я был шокирован. Он содержал непонятные куски кода на Си, сообщения об ошибках и что-то, похожее на лог-файлы. После небольшого расследования мы установили, что причиной этому была наша DRBD.

Исходная статья годовалой давности, но всё равно весьма полезный приём, например
если апач жрёт много ресурсов, не хватает памяти на сервере, тормозит база данных и т.д.
Просто положить готовые страницы в виде файлов и всё.
Притом даже если будет сбой бэкенда (ошибки HTTP 500, 502, 503, 504) - всё равно nginx сможет вернуть рабочую страницу.
---
23 марта вышел nginx 0.7.44, в нем наконец то появилось обещенное кеширование в модуле проксирования. Что нам это дает?
Как правило nginx используют для проксирования на всевозможные тяжеловесные веб сервера, которые долго и тяжело обрабатывают запросы. Не даром среди модулей nginx присутствует замечательно выполненный модуль upstream, который позволяет гибко балансировать нагрузку при проксировании. Теперь же, при наличии большого дискового кеша, nginx сможет сам обрабатывать такие запросы, не беспокоя при этом бекэнды.