Я бегу:
Ubuntu 10.04 LTS Server AMD64 in a 512MB XEN paravirtualized environment.
lighttpd v1.4.26
PHP v5.3.8
MySQL v5.1.41-3ubuntu12
Проблема в следующем:
Сначала я начал с «учетной записи 256 МБ», которая является ложью, поскольку она регистрируется как 245 МБ с использованием параметра free -m. Я обнаружил, что после того, как я запустил систему, память начала медленно исчезать, что, как я позже узнал, было диском в кеш памяти / буфер, но это все равно заставило меня нервничать, так как это выглядело как утечка памяти. Конечно же, когда он достиг максимального объема памяти, сервер упал. Я подумал, что, возможно, что-то не так с моим кодом или что я использую версию нового PHP с ошибками. Поэтому я изменил размер своего облака с 256 на 512, что также является ложью, поскольку оно составляет 496 МБ, и пусть это работает. Через неделю память снова заполнилась и сервер упал.
Для справки, я не использую drupal или php-nuke или что-нибудь предварительно связанное или раздутое. Я попытался выполнить принудительное обновление с максимальной версии PHP v5.3.2 LTS до версии 5.3.8. Для моей подкачки установлено значение по умолчанию 60.
вот моя память, как она сидит сейчас:
total used free shared buffers cached
Mem: 496 187 308 0 32 65
-/+ buffers/cache: 89 406
Swap: 1023 0 1023
Сайт почти всегда остается на уровне 89 МБ, но буферы и кэш продолжают расти. мой обходной путь - я создал ежедневный cron с echo 3 > /proc/sys/vm/drop_caches. Это работает уже 3 недели, но меня беспокоит, что, когда сайт станет популярным, этот метод взлома не сработает. Я здесь, чтобы спросить вас, ребята, которые знают об этом сценарии гораздо больше, чем я, что мне делать дальше?
Я полностью готов получить любые данные, которые помогут вам диагностировать это.
Мое личное предчувствие - несовместимость с XEN и Ubuntu, поскольку я предполагаю, что XEN говорит, что есть реальные 512 МБ памяти для использования, когда ее всего 496, или что XEN говорит, что есть 16 ГБ памяти для использования в качестве неправильного пропорционального распределения виртуальной машины. Не знаю, как это подтвердить.
Моя догадка сбылась! Похоже, что предварительно созданный образ PV, который я выбрал, не создал должным образом раздел подкачки, который Linux мог бы идентифицировать и использовать. Таким образом, после того, как файловый кеш заполнил всю память, система перешла в кеш, и либо она действовала так, как будто было 0 МБ подкачки, либо запаниковала и зависла, что-то вроде цикла кеширования / подкачки.
ИСПОЛЬЗУЙТЕ fdisk -l
вот примеры различных файловых систем, которые я исследовал. (PV означает паравиртуализированный, HVM означает полностью виртуализированный в среде XEN)
Пользовательская / чистая установка HVM через CDROM-ISO:
Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001d37d
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1871 15021056 83 Linux
/dev/sda2 1871 1958 704513 5 Extended
/dev/sda5 1871 1958 704512 82 Linux swap / Solaris
Предварительно построенные PV / HVM:
Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00084eb7
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 96256 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 13 75 499712 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3 75 1958 15130643 83 Linux
Неудачный PV:
Disk /dev/sda1: 20.4 GB, 20401094656 bytes
255 heads, 63 sectors/track, 2480 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sda1 doesn't contain a valid partition table
Disk /dev/sda2: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sda2 doesn't contain a valid partition table
Зачем вам отказываться от буферов и кешей? Свободная память - это потраченная впустую память - все современные операционные системы, включая Linux, активно кэшируют такие вещи, как пути к каталогам, активно используемые файлы и т. Д., В ОЗУ, поскольку доступ к ОЗУ безумно быстр по сравнению с жестким диском.
Если какому-либо приложению внезапно потребуется оперативная память, кэшированная оперативная память будет немедленно освобождена для этого приложения. Это очень быстрая операция, не вызывающая заметного снижения производительности.
Итак, в Linux вы фактически рассчитываете свою свободную оперативную память с помощью total - (free + buffers + cached).