Случвало ли ви се е да търсите нещо с grep но да има толкова много файлове които трябва да бъдат претърсени, че да не можете да го направите. Ето го решението :) :

find $PWD -type f -print0 | xargs -0 grep Tyrsen_String

Ето един пример как да спрете потенциална fork бомба

Редактиране на /etc/security/limits.conf :

vi /etc/security/limits.conf

ribok hard nproc 300
@mishka hard nproc 50
@buba soft nproc 100
@dhstudio hard nproc 200

След като се редактира и записа файла ще пуснем бомбата в bash (Bourne Again SHell):

:(){ :|:& };:

Ако всичко е наред реално няма да се случи нищо лошо :) , но ако не е машината ще се overload и дори има вероятност да не е възможна ssh връзка.

Днес проверявам статистиката за мрежовото натоварване и направо щях да падна :). Доиде моментът в които ще активирам mod_deflate (модул на Apache за компресиране на съдържанието). Междо другото интересен факт е, че почти всички големи сайтове в България и по Света ползват mod_deflate.
След като го активирах за 30 секунди (Благодарности на Hipo) сега резултата е следния:

http://www.kakvo.org is gzipped
Original Size: 15 KB
Gzipped Size: 4 KB
Data Savings: 73.33%

На този етап ще пожертвам използваните процесорна мощ и памет за по- бързо зареждане на kakvo.org от потребителите и спестяване на мрежов трафик.

Пълната и кратка статия се намира в kakvo.org-> ЛИНК

Днес ми се случи една интересна случка с PuTTY 0.60 която за първи път видях преди няколко години.

На една от машините ми се наложи да спра единия интерфейс т.е. може би щеше да ми се наложи и затова се бях приготвил като на най- близката машина на windows отворих putty и просто си приготвих "ifconfig ethX down", но него изпълних. Не го изпълних защото идеята беше бързо да го сваля ако се наложи… Не се наложи и затворих putty, след което веднага получих съобщение че интерфейса е паднал. Проблема беше че, когато напишете някаква команда в PuTTY без да я изпълните и след това затворите PuTTY тази команда се изпълнява.

Пример: Отворете PuTTY и напишете 'echo "dzak" > /tmp/puttydzak.txt' и сега затворете PuTTY от Close. След това влезте отново в машината и ще видите, че /tmp/puttydzak.txt е там :)

Извод: Преди да затворите PuTTY (говоря за Close) изтрийте командата ако има такава и след това го затворете другия вариант е "exit" :).

За да изтеглите PuTTY, моля натиснете ТУК за да бъдете пренасочени към официалния сайт на PuTTY за download- ТУК

Вчера посещенията на kakvo.org  надхвърлиха 11 000 и машината клекна. Клекна до толкова, че mysqld и apache2 заеха 100% и дори не можеш да се логнеш в машината нормално, а след известно време(20 сек.). За целта първата и най- основна част от решаването на този проблем е оптимизирането на mysql и apache2. След няколко огледа и мъки в натоварената машина забелязах, че полетата за "превод от" и "превод на" са тип "text" и не са индекси. В този случай когато се търси конкретен превод със заявка "… where превод от='търсен превод' " отнема 1.2 сек. и сериозно натоварва машината. Мислех 100 часа :P и реших да добавя едно поле "превод_md5" char(32) в което да пиша md5 на "превод от" и което ще бъде index. По този начин когато се търси превод не се изпълнява старата заявка където се търси самият превод, а новата в която се търси md5 на превода. Благодарение на уникалните и индексирани md5 хешове на таблицата, заявките се оптимизираха до заветните 00.00 сек. за изпълнение, а употребата на MySQL падна до 10%. Сега машината е във война с племето на Apache, но пък за сметка на това е в съюз със ордена на MySQL. Започвам да мисля още 100 часа как да подобря дипломатическите отношения на машината с племето на Apache.

Наложи ми се днес да оптимизирам една машинка, че доста се понатовари. Ето примерни стойности:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
StartServers 10
MinSpareServers 10
MaxSpareServers 15
MaxClients 200
MaxRequestsPerChild 1000

С новите стойности от 20% cpu падна на 3%.

Днес реших да прехвърля една база от MyISAM в InnoDB и при прехвърляното получих следната грешка:
mysql> alter table pcdict_words ENGINE = InnoDB;
ERROR 1214 (HY000): The used table type doesn't support FULLTEXT indexes

Това се получава защото в таблицата имам няколко индекса "Fulltext". Преди да прехвърлим
към InnoDB трябва да видим които са Fulltext индексите и да ги премахнем. За да видим индексите се изпълнява
следната команда:
mysql> SHOW CREATE TABLE pcdict_words\G
*************************** 1. row ***************************
Table: pcdict_words
Create Table: CREATE TABLE `pcdict_words` (
…
FULLTEXT KEY `worde` (`a`),
FULLTEXT KEY `description` (`d`),
…
) ENGINE=MyISAM AUTO_INCREMENT=3217 DEFAULT CHARSET=cp1251
1 row in set (0.00 sec)

Сега ще премахнем двата индекса Fulltext със следните команди:
alter table pcdict_words drop index `word`;
alter table pcdict_words drop index `description`;

Сега отново конвертираме от MyIsam към InnoDB :
mysql> alter table pcdict_words ENGINE = InnoDB;
Query OK, 3203 rows affected (0.54 sec)
Records: 3203  Duplicates: 0  Warnings: 0

Voila :)