it

В ночь с 30 на 31 октября 2011 года перевод времени производить не нужно!

Перевод времени на зимнее/летнее время в России и Белоруссии отменили.
При этом, если на компьютере обновления/настройки зоны не от 2011 года, то скорее всего будет автоматический перевод на -1 час (зимнее время).

Особенно важно это для серверов и сисадминов, соответственно :)
Далее подробности настроек:

Или как перегнать память из 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.