migration postgresql => mysql

есть достаточно большое количество statements, которые после запуска не могут быть rollback. список: для 5.0, для 5.1, то есть mysql не является ACID compliant, хотя оно заявлено.

drop table if exists temp_test_one, temp_test_two;

begin;
create table temp_test_one (a int, b int);
rollback;

-- fail here, create table caused implicit commit
create table temp_test_one (a int);


begin;
alter table test1 drop b;
rollback;

-- fail here, because alter table also caused implicit commit
alter table test1 drop b;

по непонятным для меня причинам, второе поле типа timestamp не может принимать значение now() при вставке, что делает возможным создание поля created только с помощью триггера. зато первое поле такого типа по умолчанию апдейтится при каждом обновлении записи. вот такая долбаная магия.

-- fail here, error: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause (WHY?)
create table temp_test_two (created timestamp default now(), updated timestamp default now());

-- fail here because first timestamp column have default now()
create table temp_test_two (updated timestamp, created timestamp default now());

create table temp_test_two (updated timestamp, created timestamp);

-- now updated column being updated on any update

триггеры может создавать только пользователь с правами super (вроде, в 5.1 они это поправили)

-- fail here if you don't have super privilege (5.0)
create trigger temp_test_two_bcreate before insert on temp_test_two for each row set new.created = now();

чюваки из mysql до сих пор не смогли написать нормального парсера, чтобы разграничивать внутренности процедур от остального sql кода.

-- fail because you don't set delimiter (stupid mysql parser can't recognize trigger end without separation delimiters inside trigger and outside)
create trigger contact_aupdate after update on contact
for each row begin
if new.contact_auth = 'ok' then
update domain set domain_authenticated = true, domain_state = 'auth' where auth_contact_id = new.contact_id;
end if;
end;

теперь про перл

mysql не может запускать сразу два statement в одном do; если сделать fork, то придется создавать новое соединение, так как старое привязано к process id.

my $dbh = DBI->connect;

my $pid = fork;
if ($pid) {
# failed because you can't launch two statements at same time
$dbh->do ('drop table if exists temp_test_one; drop table if exists temp_test_two; ');
} else {
# failed because cloned dbh doesn't work
$dbh->do ('drop table if exists temp_test_one, temp_test_two;');
}

короче, если нет возможности использовать что–то другое, то можно, иначе — нужно как можно быстрее избавляться от mysql в пользу postgresql и/или sqlite.

perl death is postponed

в последнее время начал работать с перлом серьезно (весь в кишках). и как–то так получилось, что уже в третий раз нахожу в нем ошибку. один товарищ сказал, что пора переключаться на java — там я буду дилетантом и не буду соваться во всякую мутную низкоуровневую поебень.

меня больше тянет к ruby, потому что по архитектуре java меньше подходит в качестве web языка. но, судя по последним данным, вряд ли я стану ruby или java специалистом.

давайте посмотрим на вот эту картинку:


по ней явно видно, что перл держится молодцом между enterprise level java и активно продвигаемым одной небезызвестной компанией ASP.NET.

как всем уже давно известно, perl не развивается. но не в том смысле, что не появляется чего–то нового. а скорее в том плане, что без большого объема общения сложно выяснить, что же стоит использовать и для каких целей. для тех же accessors в перле есть не один десяток модулей. то же касается web frameworks, ORM. короче, трендов нет, есть одна глобальная помойка под названием cpan. нет инструментов и удобных frameworks. но есть куча перлового кода, который был написан и будет написан и все это барахло нужно поддерживать.

волшебные слова типа Catalyst и Moose оставьте при себе. в реалиях сегодняшнего дня у них нет достаточного уровня производительности: http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/ . если охота более свежих тестов, то в компании, где я сейчас работаю, используется Catalyst и при потреблении памяти в 500 мегабайт он умеет обслуживать не более 10 простых запросов в секунду. Moose же работает в 10 раз медленнее моих самописных accessors, и это в самом простом случае, когда они не типизированы. простите, но это лажа.

memory organization and management in mac os x

только для 10.5

некоторые из указанных здесь данных справедливы только для 10.5. то есть я предполагаю, что, как минимум в 10.4 inactive память не могла быть помещена в swap.

чипы и диски

системе доступны кэш память процессора (cpu cache), физическая или оперативная память (ram) и память подкачки (swap). кэш память процессора — самая быстрая из имеющейся памяти. она напрямую отдает данные процессору, но за все приходится платить: она же самая дорогая и поэтому размер ее чрезвычайно мал. управление ею возможно, но при программировании под mac os x скрыто, можно лишь сравнивать насколько архитектура процессора соответствует размеру кэш памяти — что является темой для отдельной статьи. в обозримом будущем интел обещает сильное увеличение объемов процессорного кэша, так что посмотрим, может все сильно поменяется. физическая память - это микросхемы оперативной памяти, память подкачки же - это файлы на диске. также система может показывать виртуальную память, но она настолько виртуальна, что не имеет отображения ни в оперативной памяти, ни на диске. не стоит путать память подкачки и виртуальную память - они не имеют вообще ничего общего. суть виртуальной памяти в том, что она выделяется по запросу приложения. но отображаться в реальной памяти начинает только тогда, когда приложение начинает операции с выделенной памятью.

так получилось, что чем медленнее сама память, тем дешевле запихать побольше ее в компьютер. поэтому кэша у процессора в пределах нескольких мегабайт, оперативной памяти в макбук можно поставить 4 гигабайта, а более медленной дисковой — аж 300 гигабайт.

приложения потребляют память при запуске и своей работе. чем интенсивнее приложение работает с объектами и чем больше количество объектов используется, тем больше потребляет памяти данное приложение. когда активное приложение перестает помещаться в оперативную память, то часть данных неактивного приложения сбрасывается на диск, в файл подкачки. впоследствии, при переключении на такое неактивное приложение вы почувствуете, что оно совсем небыстро отвечает в течении небольшого промежутка времени - это данные, попавшие в файл подкачки, возвращаются в физическую память, а другое неактивное приложение помещается в swap. привет, пляжный мячик!

системная память

система различает в оперативной памяти несколько секций: wired, active, inactive и free. обычно, пользователь, замечая, что у него почти не осталось свободной (free) памяти, начинает выгружать приложения. количество свободной памяти после данной процедуры увеличивается, но несильно. система с двумя гигабайтами памяти, в которой запущен один только finder, может иметь свободной лишь 100 мегабайт. и это нормально.

wired память - это, зачастую, лишь память ядра системы (ну и WindowServer). wired память не имеет шансов попасть в swap. больше она ничем не интересна.

active память - это память всех приложений. то есть если приложение загрузилось, то оно «отъело» кусок active памяти. если приложение загрузило файл и держит содержимое в памяти, то оно отъест еще кусок. возможно, часть такой памяти превращается в inactive, но условия, при которых это происходит и что именно становится «неактивным» — мне неизвестно.

inactive память предположительно не имеет никакого отношения к приложениям. этой памятью управляет система, кэшируя обращения к файлам на диске. то есть если приложение прочитало файл на диске, то содержимое этого файла будет сохранено системой внутри inactive памяти. если приложение вторично пытается прочитать файл и файл не изменился, то с большой вероятностью он будет прочитан из памяти, без обращения к диску. эта память также не помещается в swap в силу бессмысленности данной операции (вообще–то так должно быть, но это не совсем так — читай далее).

free - это память, которую не использует ни одно приложение. количество свободной памяти не может опуститься ниже некоторого предела, поэтому вы вряд ли сможете увидеть значения типа 500 килобайт памяти свободно. но если значение опустилось менее 5 мегабайт, то скорее всего либо у вас уже все тормозит, или вы очень скоро это почувствуете.

сразу после загрузки у вас будет очень много свободной памяти, которая по мере работы будет активно превращаться в active и inactive. и если с active памятью мы ничего сделать не можем, система распорядится ею сама, то размер inactive памяти можно менять.

вообще–то есть довольно сильная зависимость от профиля вашей работы. если вы работаете с небольшим количеством файлов, но с приложениями, которые перелопачивают большое количество данных, то, с большой вероятностью, у вас будет больше занято active памяти. в случае копирования и чтения множества файлов — inactive память вырвется на первое место.

приоритеты

память подчиняется определенным приоритетам, которые выглядят как (у всех так нарисовано):

wired > active > inactive > swap

это не совсем верно. wired не имеет шансов попасть в swap. кроме того, я за много попыток не смог добиться (или не смог увидеть) попадания active памяти в inactive.

так что схема примерно такова:

inactive > swap, active > swap

то есть в случае нехватки памяти, active и inactive могут быть помещены в swap, причем сначала помещается inactive память, а потом active. если насчет active все понятно, то почему inactive, которая (фактически) является файловым кэшем, помещается в swap? этого я понять не могу, но результаты тестов показывают нам именно это.

волшебная inactive память

поработав за компьютером некоторое время я наблюдаю следующую картину:



для того, чтобы определиться с inactive памятью, я решил скопировать 1 гигабайт данных с помощью команды «cp» в терминале («Finder» не использует кэширование при копировании файлов):



все параметры в норме, полет нормальный, inactive память подросла на гиг. давайте посмотрим, что будет, если я попрошу у системы 2 гига памяти и запишу в них данных, а потом освобожу эту память. на первой картинке — процедура отъедания памяти, а на второй — после того, как я покликал по активным GUI приложениям и проверил, что они не залезли в swap:





вроде бы все в норме, только там есть волшебная строчка, на которую стоит обратить внимание: swap used. если сравнить с начальной картинкой, то в свопе оказалось полгига inactive памяти. фигасе, сказал я себе, когда это увидел. может, у меня скриншоты неправильно скриншотятся? я выгрузил все приложения и увидел следующую картину:



то есть в свопе находится inactive память, которая не была нужна ни одному из загруженных приложений. дальнейшие мои опыты не смогли вытащить эту память из swap. она осталась там до перезагрузки. естественно, после перезагрузки памяти у нас до фига:



еще одно наблюдение, которое я сделал по мере тестов — mach_kernel и WindowServer кушают память (wired память). причем, в случае выгрузки приложений, они ее не возвращают системе, а в силу того, что это wired память, то и в swap ее не отдают. а это значит, что в случае, если они выросли слишком сильно (у меня бывало и по полгига на каждого), никаким образом, кроме перезагрузки, нельзя вернуть память, сожранную этими двумя процессами, в систему.

inactive, active => free

в случае необходимости, вы можете освободить большую часть inactive и active памяти. как показывает вышеприведенный эксперимент, часть inactive памяти действительно освободится, часть же перейдет в swap. для этого вы можете воспользоваться программой ifreemem или волшебным скриптом, который просто нужно запустить в терминале или сделать action в automator:

perl -e 'my $a = []; $a[5*10**8] = 1;'

меняя циферки, вы можете управлять размером освобождаемой памяти. вышеприведенный пример освобождает почти два гига памяти. с помощью perl вам не удастся освободить больше, чем три с небольшим гигабайта. насчет ifreemem не знаю.

после запуска подобного скрипта в системе с небольшим количеством свободной (free) памяти, фотошоп начинает грузиться и работать быстрее, потому что ему не приходится биться за каждый килобайт оперативки с неактивной памятью. но за все нужно платить. в случае, когда у вас действительно немного неактивной памяти, а большая часть памяти активна, то активная память уйдет в своп и вы получите однозадачную операционную систему — переключение на другие приложения будет исключительно мучительным (конечно, если у вас не mac pro с raid 5 из 8–ми дисков).