Я раньше выполнял мой сайт от VPS на 4 ГБ. С течением времени мои потребности устройства хранения данных выросли, и я закончил тем, что переместился в выделенный сервер на 3 ТБ. Как дополнительная льгота, у меня теперь было 32 ГБ RAM. Хотя я признаю, что действительно не знал, что сделать с ним.
Время настало, чтобы я шел дальше снова, или к полю с 8 ТБ +, или разделять на основное поле и контейнер для хранения.
Вопрос, сколько RAM делают я хочу/нуждаюсь на своем единственном/основном поле.
Мой сайт генерирует 2 миллиона просмотров страницы в месяц и архивирует вперед в очень достойном темпе в данный момент.
Это - сайт PHP с сервером MySQL. Я действительно не знаю что метрики дать, чтобы помочь Вам ответить на мой вопрос...
Прямо сейчас свободный-m дает
total used free shared buffers cached
Mem: 32068 30937 1131 82 1314 22705
-/+ buffers/cache: 6917 25151
Swap: 1023 446 577
Таким образом, это говорит, что 25 ГБ, свободных в данный момент, я думаю?
Я все еще нахожу меня отказывающимся переместиться в поле на 16 ГБ. Несомненно, я не использую полных 32 ГБ, но возможно я мог учиться...
Я думаю, что этот вопрос очень близок к Можете ли вы помочь мне с планированием емкости?, и многие советы здесь применимы.
Но я все равно отвечу, и все сводится к мониторингу. У вас есть сервер, делающий два миллиона просмотров страниц в месяц, с 32 ГБ памяти? Это не дешево, и как таковой он должен быть инструментирован до сантиметра своей жизни. Вы должны следить за ним из вне системы, вы должны точно знать, о чем говорят эти данные, и у вас должна быть хорошая историческая информация, на которую вы можете ссылаться.
Вот старый график munin (2012) из моей коробки Colo'ed:
Он был взят сразу после того, как я обновил шасси от (очень) старого моба с 1 ГБ ядра, до одного с 4 ГБ; я хотел бы иметь сохраненное изображение до обновления, но я этого не делаю. Интересная статистика - строка "committed", это объем памяти, который ядро обещало всем приложениям; на этом графике он составляет в среднем 1.1Гб, а максимум - 1.2Гб. Вот почему я сделал апгрейд: он сказал мне, что системные вызовы памяти превысили то, что у меня было в ней, и на сколько.
Вот последний график, показывающий мне прошедший год:
Как вы можете видеть, коммитированная память выросла, отчасти потому, что ящик делает больше того, что он делал раньше, отчасти потому, что он делает некоторые новые вещи, а отчасти потому, что кернелы становятся толще с течением времени. Но это также говорит мне о том, что даже в худший день года (3.22 Гб), она не превышала физическую память; что использование памяти подкачки остается незначительным; что зафиксированная память не сильно растет в течение года.
Это означает, что я могу спокойно пренебречь памятью при моем следующем цикле замены оборудования, и, возможно, после этого, при условии, что у меня есть адекватный подкачка. Если бы я все еще работал на 32 битах (а это не так), это также дало бы мне некоторое представление о том, когда я буду вынужден перейти на 64-битную операционную систему, так что я мог бы запланировать это.
Теперь, по вашему собственному признанию, у вас нет исторических данных, и вы не знаете, что означают данные, которые у вас есть. Извините, но я не думаю, что мы сможем вам чем-то помочь; как говорится в связанном ответе:
Существует ряд факторов, которые играют важную роль в планировании мощностей... делая надлежащий анализ этих и других факторов выходит за рамки простой сайт вопросов и ответов: Они требуют детальных знаний о ваше окружение и требования, которые только ваша команда (или Консультант с адекватной компенсацией) может собирать эффективно.
Я пишу этот совет в основном для других, кто приходит и читает этот вопрос. Но если вы думаете, что можете уклониться от решения об апгрейде на месяц, поместите какой-нибудь мониторинг в сегодня , убедитесь, что он работает, поймите, что он вам говорит, и пусть он работает целый месяц, прежде чем вы должны принять решение.
.