У меня есть сервер с 4 ГБ оперативной памяти. На нем установлена 32-битная Slackware Linux 12.1. Конечно, он не использует все 4 ГБ оперативной памяти. Вскоре я хотел бы увеличить ОЗУ до 8 ГБ и ищу способ, которым система может его использовать. Система используется как сервер базы данных и в течение дня находится под высокой нагрузкой.
AFAICT, у меня есть два варианта: остаться с 32-битной и пересобрать ядро и потерять некоторую производительность. Или пойти с 64-битной и переустановить все. Глядя на 64-битные версии Slackware, я мог запустить -current или Slamd64.
Теперь к вопросам:
Стоит ли мне использовать 32-битную версию или 64-битную?
Если я перейду на 64-битную версию, мне следует использовать -current или Slamd64?
P.S. Я надеюсь получить ответы от кого-то, кто действительно использует любую из этих конфигураций в производстве, а не просто копирует / вставляет то, что я мог бы найти через Google.
Память для каждого процесса в 32-битных системах составляет 4 ГБ (по умолчанию из них 3 ГБ для процесса и 1 ГБ для ядра). Если вы хотите, чтобы ваша база данных имела доступ к большему объему памяти / на процесс /, у вас мало выбора, кроме как установить 64-разрядную операционную систему. Если ограничение в 3 ГБ на процесс вас не беспокоит, вы также можете оставить текущую настройку. Между прочим, есть и другие варианты разделения 3GiB / 1GiB, но они не помогут вам в вашей конкретной ситуации.
Существуют и другие ограничения на использование памяти для каждого процесса в форме так называемой «ZONE NORMAL», которая никогда не превышает немного ниже 1 ГБ (точнее, 896 МБ). При использовании памяти более 1 ГБ (ZONE HIGHMEM) ядро должно отображать эту память в ZONE NORMAL, создавая дополнительные возможные узкие места. ZONE HIGHMEM не существует в 64-битной системе, в которой все является ZONE NORMAL. Это также может быть хорошей причиной для перехода на 64-разрядную версию.
Что касается части «наличие в производстве»: я даже не знаю, какую базу данных вы используете. Мои установки Oracle почти всегда работают с 64-разрядной версией по той причине, которую я указал выше. Однако я не использую Slackware в производственной среде и не знаю никого, кто бы это делал.
Мои 0,02 евро: перейти на 64-битную версию. Повторная установка тривиальна по сравнению с возможными преимуществами.
Большинство современных 32-разрядных процессоров поддерживают PAE, что позволяет им обращаться к более чем 4 ГБ физической памяти, хотя один процесс может видеть только 4 ГБ за раз. Ядро займет часть этого адресного пространства. Этот пост в Stackoverflow обсуждает, как работает PAE.
Многие операционные системы (включая Linux и MS Windows) предлагают API, который позволяет вам управлять MMU и наложениями страниц в виртуальном адресном пространстве процесса и из него. Эта возможность позволяет вам использовать дополнительную память для дисковых буферов. Однако, насколько мне известно, единственной платформой СУБД с прямой поддержкой для этого является MS SQL Server.
Дополнительная память улучшит производительность чтения вашей базы данных (что, вероятно, улучшит вашу общую пропускную способность), но производительность записи будет ограничиваться вводом-выводом. Если у вас низкий процент попаданий в кэш БД (скажем, менее 95%), дополнительная память, вероятно, улучшит вашу общую пропускную способность. В противном случае вам может потребоваться взглянуть на свою дисковую подсистему (см. 1 ниже).
Предполагая, что вам нужно или вы можете извлечь выгоду из большего объема памяти, лучший подход - перейти на 64-битную платформу. Современный сервер Xeon или Opteron позволяет установить до 32–144 ГБ в зависимости от модели. Вероятно, это будет ваш лучший вариант.
Думаю, было бы лучше задать вопрос: «Зачем мне оставаться с 32-битным ядром?»
Я перешел на 64-битную версию на каждом оборудовании, которое ее поддерживает, как только смог, и ни о чем не жалею. На работе мы запускаем серверы PostgreSQL на 64-битной CentOS 5 с 32 ГБ оперативной памяти, и это довольно здорово (за исключением некоторых ограничений, связанных с самим PostgreSQL, но не имеет ничего общего с 32 или 64 битами).
Я почти в том же сценарии, что и ты (Есть ли причина использовать 64-битный MySQL (и ОС) в небольших базах данных?), и из того, что мне удалось выяснить: 32-битный MySQL не может использовать более 2 ГБ ОЗУ на экземпляр, независимо от того, что вы делаете с ядром.
Если вы не используете MySQL, ситуация может быть другой.
Основная опасность работы в 32-битной системе с большим количеством highmem (более 8 ГБ) заключается в том, что ядру может потребоваться выделить больше данных, чем помещается в ZONE_NORMAL. Это означает, что машине может не хватить памяти, даже если верхняя часть памяти все еще свободна.
Другая проблема заключается в том, что система будет более агрессивно восстанавливать структуры данных ядра, такие как кэшированные inodes, заголовки буферов и другие кеши, которые могут повысить производительность системы.
Третья проблема заключается в том, что в 32-битной системе ни один процесс не сможет эффективно использовать более 3 ГБ памяти. Это означает, что покупка более 4 ГБ памяти полезна только в том случае, если ни одному из процессов в вашей системе не требуется вся память.
По этим причинам рекомендуется, если вы покупаете систему с объемом памяти более 4 ГБ, вам следует подумать о приобретении 64-разрядного процессора и установке 64-разрядной операционной системы. Разницы в цене между 32- и 64-битными системами практически не существует, так что больше не нужно испытывать боли highmem ...
64-битный - единственный способ. Для 32-разрядной версии это изобретательный способ получить> 1 ГБ, и еще больший взлом для> 4 ГБ.[1] Вы говорите, что это сильно нагруженная система, так зачем тратить циклы на то, чтобы добраться до памяти, если ее можно отобразить напрямую?
Единственная причина, по которой вы должны использовать 32-битную версию, - это поддержка поставщика. Поскольку вы используете Slackware, я сомневаюсь, что это может быть причиной.
[1] См., Например, «Ограничение выделения памяти Linux на 32-разрядной платформе», из Руководство по установке и эксплуатации UGS NX Nastran 5.0, в котором кратко упоминается барьер в 1 ГБ.
64 бит + больше оперативной памяти, если вы используете innodb, тогда установите inndb_buffer_pool_size примерно на 70-75% от общей оперативной памяти вашей системы. Настройте размеры кеша. Если вы используете последние версии MySQL, настройте каталог / tmp на использование tmpfs (памяти), что позволит MySQL создавать временные таблицы в памяти, а не на физическом диске. Убедитесь, что MySQL настроен на использование / tmp для временных таблиц.
Если вы хотите увеличить объем памяти, у вас нет выбора, кроме как запустить 64-битное ядро. Вы можете сохранить 32-битную пользовательскую среду, если хотите, но каждый процесс будет ограничен максимум 2 ГБ (возможно, 3 ГБ). Вам не нужно переустанавливать все, просто новое ядро.
Большинство людей отвечают на вопрос №1, но позвольте мне вмешаться в вопрос №2.
Если вы решите запустить 64-битную Slackware, у вас действительно будет только один выбор: Slackware64. Slamd64 был неофициальным портом Slackware, который больше не нужен теперь, когда у Slackware есть официальный 64-битный порт. Что касается версий, у вас есть выбор из 13.0, 13.1, 13.37 и текущих выпусков Slackware64. Также обратите внимание, что 14.0, скорее всего, выйдет в ближайшее время, так что вы можете дождаться этого.