BG Tech Blog

Текущата команда изтрива файлове по-стари от 360 минути.

find $LOCATION -name $REQUIRED_FILES -type f -mmin +360 -delete

$LOCATION – път от където да започне търсенето на файловете
$REQUIRED_FILES – име (regex) за търсене на файлове

Преди известно време трябваше да се синхронизират файлове от една машина към втора. Проблема беше, че втората машина бе вътрешна за определена мрежа и през нея можеше да се достигне само чрез трета машина, която служеше в случея като буфер между двете.
Решението беше на буферната машина да се “вдигне” SSH тунел и връзката да се осъществи буквално през нея.

Вдигането на тунел в ssh не е от най-трудните неща и се постига доста лесно, с една команда:

ssh -f blagomir@casper -L 123:blagomir.com:456 -N

-f означава, че ssh процеса ще се пусне в background
-L 123 – процеса ще слуша на порт 123

Цялата команда се тълкува по следния начин:
ако потребител blagomir на машина casper (тук се пише IP на машината, вместо името й) се свързва през порт 123, той се пренасочва към порт 456 на машина blagomir.com

Посочените по-долу тестове са написани от Dmitry Baranovskiy в неговия блог под заглавието “So, you think you know JavaScript?“. Интересни са и затова ги copy/paste-вам тук.

Можете ли да отговорите какво ще върне всеки alert() докато четете кода, без да го тествате?

if (!("a" in window)) {
    var a = 1;
}
alert(a);

var a = 1,
    b = function a(x) {
        x && a(--x);
    };
alert(a);

function a(x) {
    return x * 2;
}
var a;
alert(a);

function b(x, y, a) {
    arguments[2] = 10;
    alert(a);
}
b(1, 2, 3);

function a() {
    alert(this);
}
a.call(null);

Ако никога до сега не е била сетвана парола, можете да го направите по този начин:

mysqladmin -u root -p PASSWORD

Ако искате да смените вече заложена парола:

mysqladmin -u root -pOLD_PASSWORD password 'NEW_PASSWORD'

Например ако паролата ви е 123 и искате да я смените на 456, това ще изглежда така

mysqladmin -u root -p123 password '456'

Можете да смените паролата и с SQL команда:

USE mysql;
UPDATE USER SET password=PASSWORD("NEWPASSWORD") WHERE USER='root';
FLUSH privileges;

Наскоро намерих стари забрвени log файлове пълни с вече ненужна информация. Съответно трябваше да се предприемат мерки по изтриването им. Проблема беше в количеството на файловете – около 211 GB, състоящи се от повече от 600 000 файла. Самото изтриване трябваше да стане без да се натоварва машината, защото все пак е production server и не трябва да се нарушава работата му.

Започнах по най-стария и лесен начин, а именно:

rm logs/ -r

За около 1 минута load avearage на машината се качи от 1 до 16. Да, тук някой от вас ще кажат, че load-а не е определящ фактор, но все пак е някаква цифра, по която може да се водим за оптималната работа на сървъра.
Значително се усещаше натоварването при работа със сайта. Всичко се случваше изключително бавно, MySQL заявките се изпълняваха за невъзможни времена от сорта на +1 сек.
Опитах да пусна същата команда, но с различен nice:

nice -n 10 rm logs/ -r

Това просто отложи натоварването. След около 10 мин пак имаше проблем с машината и трябваше да търся ново решение. След кратко ровене в google, намерих няколко статии, гласящи, че може да се направи нещо като unlink на самата директория и тя да изчезне заедно с файловете в нея за около секунда 🙂 Да, но не. При подобно изтриване на директория/файлове, те не се изтриват физически от диска, а просто системата вече не линква към тях. Следователно не се освобождава място на диска. Другият възможен проблем е, че при рестартиране на машината, като се пусне fsck ще се опита да оправи проблемите, а именно да изтрие файловете, към който няма “референции”. Това може да доведе до счупване на цялата файлова система и да си навлечете още по-големи проблеми.

Моят съвет е – изтриите си файловете. Може да отнеме повече време (1-2-3 дни), но ще сте сигурни, че няма да имате проблеми в последствие.

Преди около седмица се изправих пред поредния “невъзможен” проблем. Незнайно как, auto_increment полето в една от таблиците се нулираше само. По първи впечатления това се случваше на произволен интервал от време, но по-късно разбрах, че причината е в един определен cron.
Въпросният cron има за цел да оптимизира и подреди базата данни. Общо взето може да се каже, че е garbage collector за доста от нещата в базата. След съответните зачистващи процедури пуснах и процедура за оптимизиране на таблиците, а именно “OPTIMIZE table X”, където Х е името на всяка една от нужните таблици.
За моя голяма изненада, след 3 дни проблеми и опити да реша проблема, се оказа, че когато правите OPTIMIZE на InnoDB таблица, auto_increment полето в нея се нулира. За справка можете да погледнете този bug report в MySQL Bugs.