На счет "креш ядра" Вы не правы. Ядро не упало. Просто случился oom killer. В обычной ситуации он убивает процесс, что ел память. Процесс дохнет и память освобождается. oom killer успокаивается. В Вашем же случае после смерти процесса dd никто память не отдаст и oom killer методично убивает init, sshd ... ну в общем пока все не убьет. Но это отнюдь не паника или падение ядра.
Собственно сам себя дополню - в случае ramfs пока не представляется возможным правильно довыделить память:
До записи в рамфс Cached: 32876 kB
После записи 10 мегабайт Cached: 43360 kB
Больше в /proc/meminfo ничего не изменилось на такой объем. Собственно я пытаюсь снизить память, но рамфс по сути не отдает ее. Получаем oom killer. Сначала он убивает dd, потом все остальное :)
Судя по исходникам ядра, пока не представляю как можно перехватить данную ситуацию или хотя бы понять, сколько записалось в рам диск.
Доброго времени суток. Самый простой способ занять память:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main (void) {
int n = 0;
char *p;
while (1) {
if ((p = malloc(1<<20)) == NULL) {
printf("malloc failure after %d MiB\n", n);
return 0;
}
memset (p, 0, (1<<20));
printf ("got %d MiB\n", ++n);
vase добавил 09.12.2010 в 01:19
По поводу ramfs все сложно. Его структура такова, что она не использует оперативную память в чистом виде (как в данном тесте), а использует дисковой кеш. Так как cloud сервис не учитывает кеш и пытается его снизить до предела (иначе Вы потратите всю память под кеш, а Вы же не хотите за это переплачивать.. или хотите? - если да, то я могу скорректировать :)).
Я попробуйю обойти в данном случае ограничение, но только если страницы памяти будут помечены как dirty. Если оно их не пометит таковыми, то увы - использовать сейчас рам диск не выйдет. Пока не будет стабилизирован cleancache в ядре и tmem. Опыты ведутся, но времени на них мало.
vase добавил 09.12.2010 в 01:20
Да, согласен. Обычно все, кто тестят cloud пытаются найти в нем ошибку и доказать, что идея плохая.
vase добавил 09.12.2010 в 01:23
Если нужна техника идея простая. Мы следим за тем сколько памяти выделенно. Если ее больше чем надо - убавляем. Это больше чем определяется из разницы между всей памятью, текущей свободной, кешем буферами. Если Эта формула дает на выходе число больше определенного снижаем на разницу, но не слишком сильно, дабы не убить систему. Как показали опыты, если оставлять неиспользуемый лимит меньше 100 мегабайт, по крайней мере центос, начинает падать. Рамфс специфичная ситуация, хотя я уверен что таких ситуаций будет много, потому что 99 процентов программ пишутся из расчета, что размер памяти не меняется. Что является архаизмом, так как хотплаг в физический сервер памяти существует уже довольно давно.
vase добавил 09.12.2010 в 01:26
Можно. Только Вы ничего не получите. Потому как скорость будет зависеть от других машин на сервере :). Это не сильно афишируется, но если идет интенсивный on demand memory одной машины с больших пределах, остальные будут проседать. Хотя и не сильно.
П.С. Тут затронут был оверсел по памяти - он возможен. Читайте рассылку по словам xenpaging.
vase добавил 09.12.2010 в 01:29
Вот это еще хорошо почитать: http://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/
Без swap диска можно предоставлять scale сервис, но только в том случае, если можно быть полностью уверенным, что используемые приложения будут забирать память кусками не более чем свободная память на данный момент времени.
vase добавил 05.12.2010 в 23:23
Ничего не понял=).
П.С. Как Подцеплять память удаленно через RDMA пока не видел...
vase добавил 05.12.2010 в 23:30
Я давно еще хотел взять сервер, со времен работы в Петерхост. Я не согласен с тем, что сильно нагруженным проектам стоит брать выделенный сервер потому, что не всегда можно предсказать и спрогнозировать какая аппаратная часть понадобится. К тому же, совсем обидно видеть, когда арендуемый сервер отвалился, потому что хостер сплавил бу железку и там что-то навернулось (raid контроллер или память..), да, поменяют быстро, может минут за 15. Но в случае летаний в облаке все произойдет еще быстрее, если конечно вообще это произойдет...
Сайтом на данный момент занимаются посредственно. На данный момент он представляет из себя сбоник всякий скриптов, которые инклудятся через ssi. Местами есть пхп вставки.
Просто сайт не построен ни на одной из CMS, поэтому его обновление и устранение косяков - дело очень долгое. К сожалению, я не знаю почему его не перевели на тот же drupal, например.
поправлено.
