ликбез: ликбез заключаетс я в гуглении на тему tmpfs vnodes sendfile aio md
http://www.google.com/search?q=nginx+tmpfs+md+sendfile+vnodes.
первая же ссылка на прекрасное объснение Игоря Сысоева.
Но не стоит обольщаться кэш файловой системы это универсальный кэш "общего назначения". Он не дает возможности тонкой настройки кеширование. Иногда это важно. Пример: аватарки, мелкую графику и thumbnails надо отдавать очень быстро, т.к. они сразу видны на странице и скорость их отдачи влияет на восприятие общей скорости загрузки страницы. а картинки побольше загружаются по клику и их можно придержать, а что то совсем тяжелое можно вообще не кэшировать если обращения единичные. То есть получается иерархия объектов в кэше:горячие, теплые, холодный. Каждый со своей политикой кеширования. Для того чтобы это реализовать идеально подходит squid, чуть с большими усилиями это можно сделать в varnish.
memcache хорош для кеширования небольших объектов, примерно одинакового размера и "только в памяти". В противном случает через некоторое время начинается процес вытеснения, фрагментации памяти и производительность заметно падает. У tarantool (от mail.ru) с управлением памятью дело обстоит значительно лучше, можно посмотреть в его сторону.
"такое же кеширование, но только в оперативную память" делает кэш файловой системы его и нужно настраивать. Если есть желание бесполезно потратить время можно поискать истории про tmpfs от авторов которые так и не смогли осилить настройку ОС.
готовое решение есть, это кеширующие прокси серверы такие как squid или varnish.
для начала, придется забыть про кеширование всего что не HTTP, т.е. например про https забыли сразу. проксировать можно, но не в "прозрачном/transparent" режиме и без кеширования.
hostmaster добавил 12.07.2011 в 13:10
для экономии дорогого 3G трафика попробуйте установить ziproxy на внешнем сервере (vds нынче стоят дешево) и настроить в squid его в качестве upstream proxy.
настройте кеширующий DNS сервер долгощивущим кешем например pdnsd
подкрутите squid чтобы он агресивнее испрользовал кэш, посмотрите в сторону wwwoffle
есть существенная разница, какой тип таблиц и как заливают дамп. больше подробностей
или стучитесь в личку, проконсультирую. (бесплатно)
точно точно, вам нужно подсунуть своё значение в Content-Length
что там было про "гарантии" и "античат" ? :))
http://krebsonsecurity.com/2011/06/antichat-hacker-forum-breach-reveals-weak-passwords/
Имеет смысл это делать чтобы было удобнее работать с этими файлами. Если же совсем не хочется заморачиваться можно "и так". На одном популярном проекте я видел 10 миллионов файлов в одном каталоге на ext3 и ничего живут. В старых ядрах Linux сильно падала производительность если файлов больше нескольких тысяч но сейчас это не актуально.
обычно файлы не считают а вырабатывают некий алгоритм который дает распределение файлов по подкаталогов (в идеале, нормальное или близкое к нему)
считаю что в вашем случае было бы удобно сделать 2 уровня вложености.
humbert, предположим что у вас есть домен mydomain.ru и сервер с IP адресом xx.xx.xx.xx
в DNS существует 2 отображения,
- ДОМЕН в АДРЕС, так называемая "прямая зона", запись типа A, запросил mydomain.ru получил в ответ IP xx.xx.xx.xx (еще есть другие типы записей в этой зоне но это уже не важно)
- АДРЕС в ДОМЕН, так называемая "обратная зона", запись типа PTR, запросил IP адрес xx.xx.xx.xx в ответ получил домен
Домен ваш, по этому всё что относится к домену и "прямой зоне" вы контролируете, т.е можете создавать записи типа A (домен -> адрес )
АДРЕС вам не принадлежит, им управляет провайдер который предоставляет вам хостинг. Он ответственный за управление блоком IP адресов из которых он и выдает IP вашему серверу. Провайдер (он же ISP/HSP) управляет "обратной зоной" и только он может создавать записи типа PTR на своем DNS сервере.
В Вашем случае сообщение может означать:
- [ наиболее вероятный вариант ] для IP xx.xx.xx.xx нет вообще никакой PTR записи (так может быть, т.к. она не обязательна). Свяжитесь с хостером и попросите сделать такую запись для вашего IP
- запись PTR не соответствует записи A. такое может быть если например провайдер создал для вашего IP запись типа PTR но она не совпадает с доменом. т.е. по запросу xx.xx.xx.xx в ответ получаем домен srv-xx.myhosting.ru а если запросить IP по этому домену то получаем адрес НЕ xx.xx.xx.xx а другой либо вообще ничего (так тоже бывает). Тут опять же надо писать письмо провайдеру/хостеру чтобы исправили.
Надеюсь понятно объяснил,
postfix по умолчанию так не делает. почтовые сервера google тоже. пройдитесь по следующему checklist.
* проходит ли проверка SPF (это можно посмотреть в заголовках письма в Gmail), если нет обязательно сделайте и желательно не all
* IP сервера отправляющего почту имеет ли PTR запись и если да разрешается ли эта запись в тот же адрес ( x.x.y.y -> mail.mydomain.tld -> x.x.y.y)
* Gmail обращает внимание на DKIM, настройте.
будут вопросы обращайтесь, проконсультирую (бесплатно).
offtopic: вот читаю иногда SE и поражаюсь "NFS не работает", "ММ репликация в MySQL это миф". вот ведь "А мужики то не знают" ...
