Вчера посещенията на 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.
Category Archives: sadmin
sadmin
Кратък стих :) за оптимизиране на apache2
Конвертиране на mysql таблица от MyISAM към InnoDB
Днес реших да прехвърля една база от 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 :)
Suhosin и максимален брой $_POST променливи
Днес ми се наложи в една html форма да сложа 500 $_POST променливи(input полета и форма с method='post') и да ги събмитна(изпратя|submit). Обаче когато ги изпратя не се случваше нищо. Странно. Започнах да изследвам проблема и установих, че ако $_POST променливите(input полетата) са 199 ги изпраща към Apache и си работи напълно коректно, обаче когато са повече от 199 не иска да ги изпрати. След 168 часа(шегувам се) се сетих, че имам инсталиран Suhosin и от него може да се ограничава именно броя на $_POST променливите. Редактирах конфигурационния файл на suhosin (или php.ini зависи как е конфигурирано) да пуска 2000 $_POST променливи и всичко се нареди както перфектно нареждане на Рубик.
/etc/php5/apache2/conf.d/suhosin.ini
# configuration for php suhosin module
extension=suhosin.so
suhosin.post.max_vars = 2000
suhosin.request.max_vars = 2000
cat interesno.php
<?php
$max_input=198; //Работи със стойностите по подразбиране в Suhosin
#$max_input=298; //Работи с НОВИТЕ стойности в Suhosin
if (!($_POST['submit']))
{
echo "<form action=" method='post'>";
for ($i=0;$i<=$max_input;$i++) { echo "<input type='text' value='$i' name='dhstudio$i'><br>"; };
echo "<input type='submit' name='submit' value='ribka'></form>";
}
else
{
foreach ( $_POST as $key => $value ) { print $key . " " . "=" . " " . $value; print "<br>"; }
};
?>
Хей за хората които не ползват Suhosin или ползват най- обикновен Apache(нямам впредвид буквално най- обикновен) с php няма да го имат този проблем т.е. могат да добавят много голям брой $_POST заявки.