След миналия месец Tuning Linux за ниска латентност на PostgreSQL, сега имаше огромна купчина тестове, извършени на две файлови системи, три пачове и два набора от параметри за настройка на ядрото. Резултатът засега е някои интересни нови данни и още едно ангажирано подобрение в тази област, които вече са в PostgreSQL 9.1 (това са три общо, другите две са кръпки за наблюдение). Ще говоря за препоръчителната практика следващия месец по време на един от моите разговори в PostgreSQL East и изпратих нещо в тази област и за PGCon през май. Тук ще говоря още малко и за задънените места, докато тези спомени са още пресни.
Основният проблем тук е, че начинът, по който PostgreSQL използва кеша на операционната система при запис, позволява натрупване на големи количества данни. Резултатът, когато контролните точки на базата данни завършат, може да бъде дълги закъснения, докато чакате тези данни да бъдат записани. Оказва се, че програмата pgbench, която идва с PostgreSQL, е наистина добра в създаването на този проблем, така че това използвах за всички тестове. Въпросите за средствата, на които реших да отговоря, бяха:
- Смяната от старата файлова система ext3 наистина ли показва подобрение на производителността при задачи от база данни? Написах нещо за връщането на XFS в Linux миналата година, което показа добро подобрение на простите сравнителни показатели. Това обаче не винаги води до подобрения в базата данни.
- Наистина ли последните настройки на Linux dirty_bytes и dirty_background_bytes подобряват латентността в най-лошия случай?
- Кои от промените в базата данни, предложени за подобряване на поведението тук, всъщност работят?
Можете да видите всички резултати от теста, ако искате да проверите необработените данни. Това, което е променено за всеки набор от тестове, е документирано и ако направите разбивка в отделен тест, можете да видите използваните параметри на базата данни и друга основна информация за ОС. Тази уеб страница е това, което излиза от моята програма за тестване на pgbench-tools, ако искате сами да опитате подобно нещо.
Резултатите не бяха много изненадващи, но бяха интересни. Всички тестове тук бяха направени с два размера на база данни. При по-малък размер на базата данни (мащаб=500, около 8GB база данни, която лесно се побира в 16GB RAM на сървъра), ext3 управлява 690 транзакции/секунда, докато при два пъти по-голям размер (scale=1000, около 16GB база данни) беше много повече търсят обвързани и управлявани само 349 TPS. XFS увеличи тези две числа до 1757 TPS и 417 TPS – съответно 255% и 19% печалба. Още по-добре, най-лошият случай на латентност за една транзакция спадна от диапазона от 34 до 56 секунди (!) на 2 до 5 секунди. Въпреки че дори 5 секунди не са страхотни, това е синтетично натоварване, предназначено да направи този проблем наистина лош. Номерата на ext3 са толкова ужасни, че все още е много вероятно да се сблъскате с неприятен проблем тук, въпреки че всъщност виждах по-добро поведение на този файлов систем, отколкото съм виждал в по-ранните ядра (това беше направено с 2.6.32).
Кръг 1: XFS печели с категоричен резултат. Не мога да препоръчам ext3 като жизнеспособна файлова система в Linux системи с много памет, ако планирате да пишете интензивно; просто не работи в този контекст. Този сървър имаше само 16 GB RAM, така че можете да си представите колко лош е този проблем на сериозен производствен сървър тук през 2011 г.
Следват настройките dirty_bytes и dirty_background_bytes. Тези две подобриха латентността доста на ext3, за сметка на известно забавяне. Най-лошото от тях е забавеното време за поддръжка при VACUUM, което не виждате в самите резултати от теста; Вече обсъдих това в предишния си запис в блога. На XFS намаляването на тези параметри е катастрофа в производителността. В по-малкия мащаб на базата данни производителността на TPS спада с 46%, а отгоре на това латентността всъщност се влошава.
Кръг 2: Не очаквайте чудеса от dirty_bytes или dirty_background_bytes. Изглежда, че те имат някакъв положителен ефект при някои обстоятелства, но потенциалният недостатък също е голям. Уверете се, че сте тествали внимателно и включете ВАКУУМ във вашето тестване, преди да коригирате тези две надолу.
След това в крайна сметка оцених три идеи за корекции към PostgreSQL като част от този последен CommitFest:
- Разпределете извикванията за синхронизиране на контролна точка към диск (fsync) във времето. Видяхме известен успех с това на натоварен клиентски сървър, когато се комбинира с известна подобрена обработка на това как други операции за синхронизиране се кешират от базата данни
- Компактни заявки за fsync. Тази идея се отдели от първата и се превърна в пластир, написан от Робърт Хаас. Идеята е, че клиентите, които се опитват да синхронизират данни с диск, могат да се конкурират с писането на контролната точка. Това, което кръпката прави, е да позволява на клиентите да изчистят опашката от fsync заявки, ако някога я намерят пълна.
- Сортирайте записите на контролна точка. Концепцията е, че ако пишете нещата в реда, в който базата данни смята, че нещата се съхраняват на диск, ОС може да пише по-ефективно. Този пластир се появи преди няколко години с някои резултати от сравнителния анализ, които предполагат, че работи, но по това време никой не беше в състояние да повтори подобренията. Идеята се вписваше в останалата част от работата достатъчно добре, че я оцених отново.
Кръг 3: След седмици на изпробване на всичко това, единственият подход от този набор, който показа подобрение при почти всички размери на натоварването, беше този за уплътняване на fsync. Оригиналният код за синхронизиране на разпределената контролна точка помогна в тази област до известна степен, но специфичната реализация, която сега е ангажирана за 9.1, работи още по-добре. Това беше почти общо 10% печалба при повечето тестове с тежки записи, които проведох. Това е страхотно подобрение за PostgreSQL 9.1 и би трябвало напълно да елиминира проблем, който видяхме да причинява много по-голямо забавяне на производствените системи тук.
Останалите идеи тук не получиха толкова положителна оценка след тежки сравнителен анализ, така че засега те се връщат на рафта. Ще продължа да събирам данни тук – някои ext4 тестове са следващото логично нещо, което трябва да опитам – и след това отново ще се върна към разработката. Получаването на 10% печалба при някои трудни натоварвания със сигурност е хубаво, но все още има твърде много поведения в най-лошия случай, за да се разглеждат проблемите със синхронизирането на контролни точки като затворена тема.
