Мале как ги мразя тия пичове от Mysql 😆 Днес си направих обновлението от mysql 5.1 до 5.5 версия и отново сървъра не запали, a в mysql log-а всичко умираше чисто и просто с:

110527  9:27:38 [ERROR] Unknown/unsupported storage engine: InnoDB
110527  9:27:38 [ERROR] Aborting

Хах се сети какво става 😀 След като почнах да забранявам настройки по my.cfg нещата палнаха чак след като забраних

skip-innodb

Луда работа 🙂 Без тази опция в конфигурацията всичко си работеше както хората, обаче това положение не ме устройваше, защото innodb не се ползва на тоя сървър и няма нужда да заема излишна памет, която така или иначе е оскъдна. След известно ровене открих проблема и съответното му решение. Ако не е зададена default storage engine сървъра няма да опознае командата и съответно няма да се стартира 😯 . Чини ми се че леко вече прекалиха в предишния си ъпгрейд от 5.0 към 5.1 нещата пак бяха с драми поне 10 от параметрите в my.cfg бяха с различни имена и поне 5 бяха драматично изрязани и не поддържани. Тоя път само един проблем 😀 Решението на проблема очевидно е задаване на default storage engine, което става с следната команда

default-storage-engine=MyISAM

От тук нататък всичко си работеше по старо му.

Пффф досега не бях си играл с толкова големи цифри за subnetting. Няма да обяснявам самия процес има достатъчно изписано в нета, как чрез мрежовата маска се смята в коя позиция се изместват 1 и 0 и от там вече се разбира до къде свършва мрежовата част и започва хост частта. Имах доста интересната задачка закачка 2 /16-ки (сиреч 255.255.0.0) или за съвсем непросветените 2 х 65534 хост адреса да ги разделя в 2 региона с по няколко мрежи – единия  с изисквания за 32к хоста, 16к хоста и 8к хоста които от своя страна трябваше да разделя на по- 4 равно подмрежи. Втория регион имаше изискване за 4к хоста, 2к хоста и 1к хоста, и пак като предишната зона всяка една мрежа на 4 равни подмрежи 😆 По принцип съм доста добър в subnetting-а но досега не си бях играл с мрежи в такива мащаби. Падна едно красиво голямо смятане но поне придобих опит с доста по големи размери от това да разделям /24-ки което се прави спокойно наум. Сега остана всички мрежи да бъдат разхвърляни по устройствата да се направят рутациите и мрежи да заработят 😀 хахаха. Диаграмата с устройствата ми наброяваше над 30 като престанах да ги боря – красота 😎

Преди да започна с глупостите искам да кажа, че не съм много напред с web hosting-а и всичко което ще напиша е опит които съм придобил в последните 2-3 месеца. Администрирам едни доста натоварен VPS по посещаемост според tyxo е в топ 80 но влиза в топ 70 ;). Та мисълта ми е, че вече след толкова време придобих разни навици и достигнах до добрите практики по един или друг начин (обикновено по трудния) :D. Няма да пиша или да навлизам в детайли на конфигурацията никак даже. По скоро ще споделя идеите над които да помислите.

  1. Обновявайте софтуера редовно. Apache, php mysql всичко си иска обновления. Дали за да закърпите дупки в сигурниста, дали заради поправени бъгове или нови възможности. Винаги дръжте софтуера си в крак с времето. По принцип рядко се пробива един сървър през апликациите обикновено през дупки в кода на хостваните неща се пробива ама да не разчитаме само на това.
  2. Apache – web server-а ви не е желателно да има активни повече модули от тези които реално ползвате. Колкото повече модули по- бавна работа.
  3. Повече потребители на същия сървър – opcode cache. Преди време писах пък и zerdion направи доволно тестове и се вижда реално ползата от тая магия. В моя случай съм избрал eAccelerator защото в реална работна среда той показва най добри резултати с пуснати всички настройки към него. По бързо зареждане по малко ядене на ресурси което респективно означава повече потребители.
  4. Притискат ви с трафика – gzip. Най лесния начин да намалите реални трафик които правите е с gzip компресия на http отговорите към клиента. Mod deflate е решението за apache. За други http server-и не съм проучвал въпроса :). Реално около 50% ми падна трафика при компресия върху html,css,js,xml. Трябва да проверя дали мога да компресирам и друг вид съдържание ще е интересно. Защото реално снимките са съдържанието което прави най много трафик в един сайт.
  5. mysql serer – горещо ви препоръчвам ако не сте се наградили с версия 5.1 да го направите. Като цяло Oracle имат някакъв малък опит с бази данни 😆 и тоя опит са го вкарали добре в 5.1 версията не съм пробвал 5.5 но и това планувам да стане скоро.  Определено се ускори работата на sql заявките може би леко падна натоварването но с не повече от 5-6% но a пък и новите функционалности за програмистите са прекрасни. Основаната такава partitions. При надграждане внимавайте какви настройки имате в my.cfg Не всички стари опции са валидни, също е добре да махнете старите библиотеки поне при CentOS 5.5 направиха проблеми при Debian нямах такива ядове. След това си вижте mysql log-а защото някои от опциите са с различни имена и е добре да ги промените ако след време минете към 5.5 да не се чудите защо не палва конфигурацията ви.
  6. sql заявките.  Задължително разрешете опцията за записване на slow query. По тези дневници можете да върнете информация на програмистите ако не сте вие за бавните заявки да се оптимизират. Колкото по малко такива заявки по малко натоварване за сървъра ви 😉
  7. Малко защита – сменете подразбиращия се порт на ssh-а ви няма нужда смотани ботове да се опитват да ви хакват. Apache го подсигурете с mod_security доста полезен модул прави филтрация на доста шитни – sql inj, rfi DDoS и прочие. Няма да спре голям хахор ама поне ламерите ще ги отсее. PHP е добра идея да се защити с Suhosin. Може да се сложи като допълнително разширение или направо като пач в php кода. Аз лично предпочитам първия по изчистен ми се струва.

Като за начало това са нещата които се сещам. Не са много а като се замисля съм направил доста оптимизации по сървъра но много от тях са доста специфични според ситуацията и няма смисъл да ги обяснявам тях като например лимитации на кешове или пък колко процеса има вдигнато apache-то. Вероятно с времето ще се сещам и за още неща които са как да кажа част от малките неща които дават големия резултат. Машината е доста добре оптимизирана за сравнение ние правим на 20к уникални посещения на ден и сме на най ниския възможен vps план load time на страниците ние не надхвърля 1,5-2 сек или ако го надхвърля е заради външните източници на реклами иначе самата страница се изплюва за части от секундата. Хора с близки позиции до нас са с не оптимизирани сървъри с доста повече ресурси от нашия и имат същите резултати. Общо взето оптимизиране му е майката и пиенето на бира бащата 😆

ps Песничката леко се връзва с тематиката 😀

Днес понеже имам повече свободно време се заиграх с дроидчето ми и направих 2 доста интересни подобрения. Общо взето резултата беше 3 пъти по бързо зареждане на системата и около 50% ускорение на апликациите. Версията която ползвах е 2.2.2.  Така какво направих

  1. Odexing – Така какво е odex и deodex е тема която нямам намерение да разглеждам сега и кои какво прави но нека леко разяснение deodex това са разни хешове чек суми и класчета дето улесняват местенето на апликациите от една системка на друга и подобряват живота на програмиста,  да ама и забавят нашата системка защото когато се стартира апликацията прави кила провери и чекове. Така стига лирика първо премахнах deodex-вете това е елементарно с следния скрипт. Пуска се с root права на вашия телефон, тои ще свърши всичко необходимо. Раз пакетира пакетира и прочие. Да знаете че може да загубите известна информация контакти и прочие затова ги архивирайте предварително!
  2. JIT enabling – just-in-time compilation това е друга благинка която е добре да се появи. Както е известно java-та не е най бързите платформи на планената както и много други програмни езици. Та затова разни умни глави се се сетили че е разумна идея вместо всеки път да се компилира апликацията и след това да се стартира по добре да се компилира веднъж и след това да се пази byte code копието. Така избягваме нужда повторна компилация ускоряваме стартирането и намаляваме необходимите ресурси. Това се оказва интеренсна задачка не заради друго ами защото файла се намираше в read only директория на телефона 😀 не че това е проблем 😉 Самото разрешване на JIT ства като се добави следния ред в файла /system/build.prop dalvik.vm.execution-mode=int:jit Как ще го отоворите и едитните си е ваша работа дали през adb или ssh си е въпрос на ваша преценка за да може да го едитнете е необходимо да изпълните следните команди на телефона
mount -o remount,rw -t yaffs2 /dev/block/mtdblock2 /system

#mtdblock2 е дяла където е маунтнат system може да видите верния за вас номер с df

echo "dalvik.vm.execution-mode=int:jit" >> /system/build.prop

#може просто да си ъплоуднете файла аз направо на ръка го оправих

sync
mount -o remount,ro /dev/mtd/mtdblock2 /system

Рестартирайте и се радвайте на новия си по бърз Android

В неделя ми беше модулния изпит (края на семестър 1) за Cisco CCNA Network Fundamentals. Като цяло беше голямо четене и учене от септември до сега. Накрая всичко се нареди но както обикновено съм недоволен  – хубавото е че си взех модула, той сам по себе си нищо не значи или поне не и в България, въпреки, че ще ми се издаде сертификат че знам всички фундаментални истини за мрежите според Cisco. Недоволен съм, че резултата ми е нисък – 85%. Надявах се на поне 90% ама шанс. Все пак не е като провал 😆 . Донякъде съм доволен вече започва истински приятните занимания които само бегло разчоплихме – рутинги протоколи и прочие. Вече всичката суха теория която се взе ще остане в миналото и започва голямата забава с рутери и суичове.

Малко ми е странно тази седмица за първи път от септември нямам за учене цяла свободна седмица след работа ще се чудя какво да правя, или пък не 😈

p.s Мале Radiohead направо ме убиха – ненормално яко парче. Чух само хубави отзиви за последния им албум.