Първо да уточниш на кое казваш сериозна и следователно на кое не-сериозна работа?

А сети ли да го сетнеш с tune2fs "-E" и после да гледаш "-l"?

А като си начинаещ в "света на линукс" защо пишеш в секцията за напреднали?

Точно това съм му казал, че ако иска всичко на готово - във форум не става. Ако предполагаш, че на дадено място има хора с еди какви си знания и се надяваш да измъкнеш от тях безплатно информация която ти нямаш то трябва да им представиш нещата така, че да не ги затруднява да ти дадат бърз отговор. Иначе е малко вероятно някой да се занимава.

Пуснал е част от mysql конфигурация и говори за дълги query-та. Като начало може да пусне slow query log-а и да каже  отделно, че за бавни query-та смята такива над секунда. След това с mysqldumpslow да ги прегледа и според каквито са резултатите ако може да ги оптимизира. Според зависи какви са таблиците за някои е по добре да се ползва myisam storage engine, за други е по-добре innodb (за отделните имаш различни опции за отдаване на хардуерни ресурси в mysql конфига). Ако не могат да се оптимизират то тогава според случая може да се сложи и някакъв caching layer м/у клиента и mysql сървъра.

Варианти много ... повече информация за mysql tuning: http://www.mysqlperformanceblog.com/

Кое му е натоварено на сървъра или гледаш само "load average", който сам по себе си не може да ти каже много. И знаеш ли какво точно го товари?

Няма как някой да ти даде еднозначен отговор или пък да го събере в едно изречение къде точно бъркаш. Трябва да си прегледаш всеки един слой от това което си натворил/наследил/купил/наел/whatever до момента и да оптимизираш всеки. Има голям шанс нещата да не са оптимизирани (изобщо или добре) и да подобриш от видимо до драстично работата на приложението което върви отгоре (дай боже да е едно), стига да знаеш какво правиш.

Но така в тъмното на малко хора им се стреля ... или ако им се стреля е за упражнение щото разбираш ли нямат достатъчно опит ;-)

Ако зададеш конкретен въпрос има шанс да получиш някакво напътствие ... но "Full LAMP stack optimization guide for dummies" никоя уважаваща себе си нинджа няма да седне да ти пише тук ;-)

http://helmer.sfe.se/
http://helmer2.sfe.se/
http://helmer3.sfe.se/

Нахвърлям и аз някакви мисли върху мнения от постовете ...

Това с натоварения мейл сървър и страдащия клиент изглежда малко преувеличено. Какъвто и да е scheduler-а за работа с блоковото устройство едва ли ще има фрапантно забележима разлика при клиента. Ако трябва да скалираш нещо такова определено според мен по-добрия вариант да добавиш повече ресурс (след допустимото стандартно "оптимизиране" на FS) под формата на повече едновременни обслужени requests за писане/четене е просто добавянето на повече  spindles/disks. Един средностатистически SATA диск повече от 200-250 такива request-а трудно прави ;-) Обслужването на такива пикове според мен не се забелязва значително ... стига наистина да са кратки.

Другото нещо за което се сещам е, че за консистенция при ext3 само journal data опцията не е достатъчна. Имат значение barrier опцията (която пък не работи през md/dm в linux) и write cache на диска дали е включен. Т.е. или едното или другото ... по-сигурния вариант е с изключен write cache.

Отделно пък ако пишеш по някакъв начин metadata + data наистина синхронно някъде, за какво ще ги пишеш втори път след това?

Дискусията е интересна.

За феновете на "перфектния", поддържан, сигурен и функционален софтуер на djb:

http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html

find path/ -type f -iname \*.php -or -iname \*.html | xargs sed -i.backup s/user\@domain.tld/pepi\@domain.tld/gi

без бекъп копия съответно:

find path/ -type f -iname \*.php -or -iname \*.html | xargs sed -i s/user\@domain.tld/pepi\@domain.tld/gi

Прочети документацията на mod_autoindex, и по специално: IndexStyleSheet директивата.

Дори ***** като теб би трябвало да го намери за под 10-15 минути това.

Това с компилирането на kernel и LVM беше яко ;-)

experimental > unstable > testing > stable > oldstable

neter,

-p tcp? къде остана udp?

[Цитат]

Цитат

-i interface (мрежови интерфейс, за който ще действа правилото)

С -i поставяш условие, че останалата част от правилото ще важи за пакети получени през описания интерфейс. Съответно с -o поставящ същото условие но за пакети излизащи през описания интерфейс.

Може би бъркаш -i опцията с еквивалента й при tcpdump и iptraf например.

[Примерен код]

VladSun,

Примерен код

$ipt -t nat -I POSTROUTING -o $extIF -p $pmProt -s $pmIP --sport $pmPort -j SNAT --to-source $sIP:$sPort

Това правило е излишно. Както и следващите две в FORWARD веригата (поне в скрипта който си написал).