ещё чуть-чуть о работе
Jun. 2nd, 2003 12:34 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaВ дополнение к этому.
В конце концов я переписал программу (она теперь есть в CVS, кстати) так, чтобы она использовала простую версию slab-аллокатора. Вот что это значит на практике. Модуль аллокации памяти выделят только блоки размером степенью двойки, от 27 (т.к. меньше не оказывается нужно в программе, вследствие того, что каждый хранящийся item вместе с контрольной структурой выходит длиннее) до 220. Для каждого класса размера (т.е. для каждого возможного размера от 128 байт до 1Mb) хранится простой связанный список свободных на данный момент блоков этого размера. Когда блок освобождается, он добавляется в этот список; когда требуется новый блок, берётся из этого списка. Вопрос, таким образом, только в том, как в этот список попадают новые свободные блоки. Когда нужен новый блок, а список пуст, вызывается malloc() и у него берётся сразу 1Mb памяти (slab), к-й делится на блоки нужного размера, и их адреса добавляются в список.
Из-за того, что у malloc()'а берётся всегда 1Mb, эта память всегда оказывается выделенной с помощью mmap() (malloc() всегда использует mmap() для запросов размером больше 128kb). Выделенные слэбы никогда не возвращаются в систему. Вследствие этого внешней фрагментации (т.е. фрагментации, возникающей вследствие образования маленьких "дырок" в адресном пространстве) нет в принципе. Зато довольно высока внутренняя фрагментация, т.е. потеря памяти за счёт того, что выделяется обычно больше памяти, чем на самом деле нужно (окгругляется до ближайшей степени двойки).
В данный момент внутренняя фрагментация составляет примерно 33%, т.е. треть памяти расходуется зря. Но нас это не слишком беспокоит. Во-первых, намного важнее, чем расчётливый расход памяти, было довести программу до состояния, когда она гарантированно бежит неограниченно долгое время без проблем — и сейчас она в таком состоянии (и последняя версия уже бежит несколько суток). Даже используемых нами сейчас примерно 5Gb кэша (разбитые на штук 6 процессов) и даже с такой внутренней фрагментацией хватает для того, чтобы очень убыстрить работу сайта. Hit rate при этом дошёл примерно до 80% (т.е. из той инфомации, что кэшируется, только 20% идёт из БД, а остальное из кэша). Во-вторых, slab-аллокатор можно сильно улучшить, чем я займусь через пару дней, наверное. Самое главное — заставить его работать с разными вариантами классов размеров, необяазтельно со степенями двойки. Это очень легко. Потом можно подобрать такие классы, которые именно в случае ЖЖ уменьшают фрагментацию. Мне ещё пока неясно, стоит ли возиться с динамическим анализом (т.е. чтобы аллокатор сам анализировал настоящие размеры запрашиваемых блоков, к-е ему передаются, и перекраивал свои класс размеров динамически) или просто обеспечить возможность чтения размеров из конфиг-файла или по протоколу.
В конце концов я переписал программу (она теперь есть в CVS, кстати) так, чтобы она использовала простую версию slab-аллокатора. Вот что это значит на практике. Модуль аллокации памяти выделят только блоки размером степенью двойки, от 27 (т.к. меньше не оказывается нужно в программе, вследствие того, что каждый хранящийся item вместе с контрольной структурой выходит длиннее) до 220. Для каждого класса размера (т.е. для каждого возможного размера от 128 байт до 1Mb) хранится простой связанный список свободных на данный момент блоков этого размера. Когда блок освобождается, он добавляется в этот список; когда требуется новый блок, берётся из этого списка. Вопрос, таким образом, только в том, как в этот список попадают новые свободные блоки. Когда нужен новый блок, а список пуст, вызывается malloc() и у него берётся сразу 1Mb памяти (slab), к-й делится на блоки нужного размера, и их адреса добавляются в список.
Из-за того, что у malloc()'а берётся всегда 1Mb, эта память всегда оказывается выделенной с помощью mmap() (malloc() всегда использует mmap() для запросов размером больше 128kb). Выделенные слэбы никогда не возвращаются в систему. Вследствие этого внешней фрагментации (т.е. фрагментации, возникающей вследствие образования маленьких "дырок" в адресном пространстве) нет в принципе. Зато довольно высока внутренняя фрагментация, т.е. потеря памяти за счёт того, что выделяется обычно больше памяти, чем на самом деле нужно (окгругляется до ближайшей степени двойки).
В данный момент внутренняя фрагментация составляет примерно 33%, т.е. треть памяти расходуется зря. Но нас это не слишком беспокоит. Во-первых, намного важнее, чем расчётливый расход памяти, было довести программу до состояния, когда она гарантированно бежит неограниченно долгое время без проблем — и сейчас она в таком состоянии (и последняя версия уже бежит несколько суток). Даже используемых нами сейчас примерно 5Gb кэша (разбитые на штук 6 процессов) и даже с такой внутренней фрагментацией хватает для того, чтобы очень убыстрить работу сайта. Hit rate при этом дошёл примерно до 80% (т.е. из той инфомации, что кэшируется, только 20% идёт из БД, а остальное из кэша). Во-вторых, slab-аллокатор можно сильно улучшить, чем я займусь через пару дней, наверное. Самое главное — заставить его работать с разными вариантами классов размеров, необяазтельно со степенями двойки. Это очень легко. Потом можно подобрать такие классы, которые именно в случае ЖЖ уменьшают фрагментацию. Мне ещё пока неясно, стоит ли возиться с динамическим анализом (т.е. чтобы аллокатор сам анализировал настоящие размеры запрашиваемых блоков, к-е ему передаются, и перекраивал свои класс размеров динамически) или просто обеспечить возможность чтения размеров из конфиг-файла или по протоколу.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-06-02 03:37 am (UTC)no subject
Date: 2003-06-02 04:55 am (UTC)Re:
Date: 2003-06-02 06:32 am (UTC)Но вообще, конечно, такого рода оптимизации нужно делать только после того, как статистика покажет, что это необходимо. 60% hit rate - это очень хорошо, так что, может быть, это и ненужно.