Comments 164
Поставьте 8 гб и почувствуйте разницу.
это как в свое время было хорошо различимо 64 и 128 мегабайт, а вот с 128 до 256 разницы было мало. именно в тот момент когда 256 только появилось еще во время 98 окон.
PS: Я уже думал что 32 битки умерли и в живых остались единичные случае или сильно упорные или с нехваткой финансов для такого перехода. Тут глядишь уже 128 бит назревает а народ еще ломается переходить или нет на 64 -)
это как в свое время было хорошо различимо 64 и 128 мегабайт, а вот с 128 до 256 разницы было мало. именно в тот момент когда 256 только появилось еще во время 98 окон.
PS: Я уже думал что 32 битки умерли и в живых остались единичные случае или сильно упорные или с нехваткой финансов для такого перехода. Тут глядишь уже 128 бит назревает а народ еще ломается переходить или нет на 64 -)
Хорошо бы, только сервер за границей находится :-) Конфигурация фиксированная.
Если поставлю памяти 8Гб вместо 4Гб, от этого ее потребление меньше не станет.
Хочу, чтобы Apache2 кушал 20Мб вместо 50.
Если поставлю памяти 8Гб вместо 4Гб, от этого ее потребление меньше не станет.
Хочу, чтобы Apache2 кушал 20Мб вместо 50.
UFO just landed and posted this here
Переезжая с сервера с 2Гб на сервер с 4Гб потенциально хочется, чтобы во вдвоем большем объеме памяти помещалось вдвое большее количество процессов.
UFO just landed and posted this here
Смысл в 64 битах только есть есть приложение которому надо вдресовать больше 2гиг памяти. Чтобы система видела больше 4 гиг есть PAE.
P.S.
надо переходить на 64 бита это да, но нафига мне адресовать больше памяти приложениям который на 32 битах себя хорошо вели? У меня лично нет потребности чемуто адресовать большие обьямы памяти на десктопе :)
P.P.S.
у меня просто старый бук :) core duo, 2GB max :)
P.S.
надо переходить на 64 бита это да, но нафига мне адресовать больше памяти приложениям который на 32 битах себя хорошо вели? У меня лично нет потребности чемуто адресовать большие обьямы памяти на десктопе :)
P.P.S.
у меня просто старый бук :) core duo, 2GB max :)
На 64 битах можно получить клевые плюшки в виде немалого ускорения для мультимедиа-программ типа кодирования видео или аудио. К тому же, как ни говорите, но PAE — это костыль :)
ну этот как раз тот случай когда нужно сразу большие обьемы адресовать. Согласитесь не всем нужны 64 бита? :) Мне концепция: «А то получается, что увеличили в машине бензобак и объем двигателя в два раза» не устраивает если мне нужены такие обьебы бензобака и движка :)
P.S.
PAE костыль еще какой! в некоторых случаях это вообще флагшток-кун :)
P.S.
PAE костыль еще какой! в некоторых случаях это вообще флагшток-кун :)
UFO just landed and posted this here
А можна пруфлинк на сравнение где видно немалое увеличение производительности при переходе на 64 бита?
попробуйте конвертнуть DV видео на макбуке с Snow Leopard сначала в 32 бит, потом в 64
ну как минимум разница полтора часа должна о чем-то говорить
ну как минимум разница полтора часа должна о чем-то говорить
Например о хреновой оптимизации на 32 битах?
Проблемы с оптимизацией какраз могут быть на x64, но это опять же стереотип, живший в головах несколко лет назад. Сейчас уже научились писать нормальные приложения адекватно оперирующие 64 разрядами.
Просто мне внушает подозрение разница в полтора часа. Разумеется, я знаю что 64 битная архитектура может дать прирост в производительности. Но не в такой же степени?!?
Я пару лет назад сравнивал на E4600 кодирование в H.264 на 32-х и 64-х битной убунте. Разница ~ 15% в пользу 64-х битной ОСи. Результаты за давностью лет затерялись на просторах тырнета.
PAE не работает для более чем 16 GiB. Кончается LowMem и OOM killer убивает машину.
OOM killer убивает только процессы. И то не любые. И делает это, когда кончается виртуальная память.
Как это связано с PAE, 16GiB и LowMem?
Как это связано с PAE, 16GiB и LowMem?
OOM killer на 32-битной архитектуре убивает процессы, когда кончается HighMem или LowMem. В случае использования более чем 16 GiB (32 GiB) под 32-битным PAE LowMem заполняется за день-два средней нагрузки, после чего OOM killer начинает убивать процессы. Что в конце концов приводит к смерти системы.
При ограничении памяти до 16GiB LowMem не забивается и OOM не вызывается. При 32 GiB забивается за 2 дня.
При ограничении памяти до 16GiB LowMem не забивается и OOM не вызывается. При 32 GiB забивается за 2 дня.
В дополнение к предыдущему комментарию, чтобы не думали что я теорией тут занимаюсь. Данное поведение замечено на наших 8 серваках с 32 GiB памяти. Срочно меняем систему на 64-битную.
Единственное из упоминаний этого феномена нашли на www.linux-mm.org/
Проблема временно решается сбрасыванием дисковых кэшей. Но помогает ненадолго. Как-только LowMem кончается начинает свою грязную работу OOM killer. При этом HighMem даже на половину не занят.
Единственное из упоминаний этого феномена нашли на www.linux-mm.org/
Проблема временно решается сбрасыванием дисковых кэшей. Но помогает ненадолго. Как-только LowMem кончается начинает свою грязную работу OOM killer. При этом HighMem даже на половину не занят.
ptgmedia.pearsoncmg.com/images/0131453483/downloads/gorman_book.pdf
Пункт 2.7 этой книжки немного объясняет в чём дело. А какое же у вас ядро?
Пункт 2.7 этой книжки немного объясняет в чём дело. А какое же у вас ядро?
Вместо Apache для php лучше использовать nginx.
Память давно не ресурс.
Смысл в 64 очевиден — можно адресовать более 4 Гб (кому мало). А вот смысл в 128 битах какой?
можно адресовать больше чем 128 Гб
думаю смысл в более быстрых процессорных операциях, возможно, будут какие-то комбинированные операции: операции над частями строк, анализ потоковой информации обработки сигналов и тому подобное…
Прогресс от математических вычислений смещается в сторону обработки текстовой информации, к быстрому ее анализу.
разработка ОС пока не догонянет железо…
думаю смысл в более быстрых процессорных операциях, возможно, будут какие-то комбинированные операции: операции над частями строк, анализ потоковой информации обработки сигналов и тому подобное…
Прогресс от математических вычислений смещается в сторону обработки текстовой информации, к быстрому ее анализу.
разработка ОС пока не догонянет железо…
В связи с этим вопрос — можно ли безболезненно сделать даунгрейд на 32-битное ядро или же возможно только переустановить ОС?
Выигрыш в том, что вашему процессу доступно адресное пространство > 4G. Если оно вам надо, конечно. Другие знающие люди утверждают, что компиляторы для 64битных процессоров способны генерировать более оптимальный код (и уже используют это для нужд системного программирования — там, фрейм задачи, фрейм вызова, все дела), но мы то знаем.
Первая вообще не в тему, т.к. скорее про маркетинг Intel, а не про технологии. Вторая… в стиле THG — с первых же строк сказки для чайников: самые первые математические сопроцессоры 8087 имели 80-битные регистры. А тут оказывается бедные учёные без 64 бит недополучали математическую точность — сиротинушки…
Все как-то забыли о том, что в x86_64 доступно аж 16 регистров общего назначения (в противовес 8 у IA-32). Это позволяет намного меньше заниматься пересылкой данных из стека в регистры и наоборот.
Адресация данных относительно регистра RIP (instruction pointer). Позволяет компилятору генерировать более эффективный position-independent код.
Адресация данных относительно регистра RIP (instruction pointer). Позволяет компилятору генерировать более эффективный position-independent код.
Прошу не путать x86_64 и ia64. ia64 — дйствительно 64х битная архитектура, а x86_64 расширение ia32
UFO just landed and posted this here
Тем не менее x86_64 и ia64 не совместимы
Пруфлинк
software.intel.com/en-us/articles/intel-extended-memory-64-technology-faq/
И короткая цитата:
«Intel® Extended Memory 64 Technology, or Intel®64, is an enhancement to Intel's IA-32 architecture.»
software.intel.com/en-us/articles/intel-extended-memory-64-technology-faq/
И короткая цитата:
«Intel® Extended Memory 64 Technology, or Intel®64, is an enhancement to Intel's IA-32 architecture.»
Так кто вообще заговорил про IA-64? Это отдельная архитектура разработанная практически с нуля, с IA-32 (она же x86) не совместима и практически никакого отношения, кроме того что так же была разработана Интелом, к ней не имеет.
Прошу показать где я спутал.
«в х86_64 доступно аж 16 регистров общего назначения (в противовес 8 у IA-32)»
х86_64 это все еще ia32
х86_64 это все еще ia32
fail, это Intel 64 — www.intel.com/technology/intel64/index.htm
х86_64 это все еще ia32
x86_64 это, как не странно, продолжение x86 (ia32) :) Причем обратно совместимое. А вот IA64 это все же не продолжение IA32, а совершенно другая архитектура.
Кстати, прошу заметить, что линейка x86 изначально вообще была 16-битная. Но сейчас все-таки говоря x86 обычно подразумевают набор команд >=i386.
А вообще я понял и признаю что моя поправка была неуместна и это мало кого интересует
и сколько это даст прироста для апача из сабжа? будет оно стоить увеличенного потребления памяти?
а почему 64 занимает в 2 раза больше памяти, сами программы же не много места занимают а вот данные хранятся в памяти не в словах а в байтах (если данных много то хранить неэкономно не получится)
вот например как в памяти хранятся картинки, звук и другие тяжелые вещи наверно еще и в сжатом виде
вот например как в памяти хранятся картинки, звук и другие тяжелые вещи наверно еще и в сжатом виде
Предположим, апач занимал 20 мегабайт.
Худший случай — вся-вся памяти, которую занимает процесс апача, состоит исключительно из одних указателей.
В этом худшем случае при переходе с 32 бит на 64 потребление памяти увеличится в 2 раза, т.е. процесс апача станет занимать 40 мегабайт, так?
А у Вас, говорите, все 50 мегабайт. Логический вывод: дело не в длине указателей?
Худший случай — вся-вся памяти, которую занимает процесс апача, состоит исключительно из одних указателей.
В этом худшем случае при переходе с 32 бит на 64 потребление памяти увеличится в 2 раза, т.е. процесс апача станет занимать 40 мегабайт, так?
А у Вас, говорите, все 50 мегабайт. Логический вывод: дело не в длине указателей?
Ещё выравнивание кода. Отсутствие некоторых команд — команды 64-бит команды исполняются быстрее, но их меньше. Всё это сильно увеличивает код. Плюс, стек в два раза разрастается — для сохранения регистров нужно в два раза больше памяти. Хотя я в упор не понимаю, каким таким образом объём динамической памяти может быт в два раза больше. Все целочисленные (и булевские) значения тоже в два раза больше в структурах занимают — вот тут уже сильный перерасход может быть. Код в разделяемой памяти хранится и не должен сильно влиять. Стек стал в два раза больше, но на задачах типа веб-сервера стек не должен быть сильно большим. Остаются динамические данные. Но там только увеличение объёма может быть за счёт увеличения размера целочисленного и логического типа. Но, блин, это как-то не правильно — это означает, что около 50% кэша и 50% передаваемых по шине данных — мусор. А удвоение кэш-памяти и пропускной способности шины на серверных задачах даёт 15% прироста производительности. Т.е. при переходе на 64-бита эти самые проценты теряются. Отсюда вывод — если правильно написать 64-битное приложение, то можно получить сильный прирост производительности и знатную экономия памяти. Но скорее всего потеряется совместимость с 32-бит на уровне исходного кода (нужны танцы с бубном вокруг целых значений и их упаковки в структуры, а современные компиляторы это позволяют через только через зад).
int и bool не увеличиваются. Увеличивается указатель, size_t, ptrdiff_t, long.
sizeof(bool) = 1
sizeof(int) = 4
sizeof(long) = 8
sizeof(bool) = 1
sizeof(int) = 4
sizeof(long) = 8
Тогдя я категорически не понимаю куда девается память :)
Вы же сами вроде сказали — выравнивание структов.
Но я не понял вот это:
>Плюс, стек в два раза разрастается — для сохранения регистров нужно в два раза больше памяти.
Но я не понял вот это:
>Плюс, стек в два раза разрастается — для сохранения регистров нужно в два раза больше памяти.
Да, я уже успел вдумчиво изучить спецификацию x64 — не требует она никакого специфичного выравнивания данных. И регистры там 32 бита (указатели 64 бита). Единственный грабель — множество регистров общего назначения, которые нужно сохранять в стеке при вызове подпрограмм, но эта проблема давно и успешно решена на множестве RISC-архитектур. Т.е. правильно написанная программа должна отличаться на проценты по потреблению памяти. Откуда такой перерасход категорически не понятно. Подозреваю кривые руки программистов и/или грандиозные глюки компиляторов.
UFO just landed and posted this here
Как выше намекнул kmike данные приложения состоят не из одних указателей. Добавлю, что скомпилировать приложение можно и как 32-битное и система будет запускать его на CPU в режиме совместимости и никаких потерь памяти на указателях не будет. Так что, автор, ищите проблему в другом.
Мне вот интересно было, почему наоборот, в 32-битной Vista объем потребляемой памяти был практически таким же, как в 64-битной (что-то около 590 метров после установки).
Берем сервер на 64-х битах
Режем на OVZ контейнеры
В каждом пускаем 32-х битный apache
???
PROFIT!
Режем на OVZ контейнеры
В каждом пускаем 32-х битный apache
???
PROFIT!
самый главный вопрос — выигрыш в плане производительности ощущается?
В линуксе разве нельзя запускать 32-битные процессы в 64-разрядной системе? В винде есть wow64, который это позволяет. Так что можно использовать более 4гб оперативки (и до 4 гб на каждый процесс), а расход памяти прогами не увеличивается.
* поправка — не больше 2 гб на процесс
32х битный процессы в 64х битном Windows могут использовать 4Гб виртуальной памяти.
Memory Limits for Windows Releases (Windows) msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx
Memory Limits for Windows Releases (Windows) msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx
Рост потребления памяти обусловлен вдвое большей длиной указателей.
Не думаете ли вы что вся информация, которую может хранить веб-сервер, есть указатели? Просто бред.
Andrey_Rogovsky предложил хороший вариант.
Если брать nginx(от 2х воркеров), то он работал шустрее на одной x86_64 машинке, чем при виртуализации на OpenVZ.
Меня всегда забавляли треды/стетьи вроде «что быстрее: x86 или x86_64?». В конце оказываются смешные результаты. Кто-то тыкает пальцем в то что x86_64, хотя в этом виновато приложение, которое работает через ia32, т.е. не распаралелливается. Кто-то считает что x86_64 работает шустрее, хотя сравнивали с медленной машинкой на x86.
Хотя формула счастья проста: берите хайэнд-x86_64 машинки для серверов и хайэнд-x86 машинки для десктопов. Конечно, всё по целям и нуждам.
Не думаете ли вы что вся информация, которую может хранить веб-сервер, есть указатели? Просто бред.
Andrey_Rogovsky предложил хороший вариант.
Если брать nginx(от 2х воркеров), то он работал шустрее на одной x86_64 машинке, чем при виртуализации на OpenVZ.
Меня всегда забавляли треды/стетьи вроде «что быстрее: x86 или x86_64?». В конце оказываются смешные результаты. Кто-то тыкает пальцем в то что x86_64, хотя в этом виновато приложение, которое работает через ia32, т.е. не распаралелливается. Кто-то считает что x86_64 работает шустрее, хотя сравнивали с медленной машинкой на x86.
Хотя формула счастья проста: берите хайэнд-x86_64 машинки для серверов и хайэнд-x86 машинки для десктопов. Конечно, всё по целям и нуждам.
а сейчас разве остались хайэнд-х86 машинки?
> виновато приложение, которое работает через ia32, т.е. не распаралелливается.
Что вы хотели сказать? :)
Что вы хотели сказать? :)
Я думал все поймут о чём я. ia32-libs. Т.е. в linux 32-битные приложения на 64-битной версии ядра можно запустить через ia32-libs.
Т.е. на 64-битном ядре запускаются приложения от 32-битного. А вот некоторые этого не знают и проверяют производительность таким глупым способом.
Т.е. на 64-битном ядре запускаются приложения от 32-битного. А вот некоторые этого не знают и проверяют производительность таким глупым способом.
ia32-libs нужны, когда у вас userspace 64-битный, но нужно запустить 32-битную программу. В этом пакете и его зависимостях как раз и содержатся основные 32-битные библиотеки.
На 64-битном ядре вполне себе может работать полностью 32-битный userpace. Только это может не поддерживаться дистрибутивом (например, насколько я знаю, Debian не поддерживает; не в смысле что не работает, а в смысле что такая конфигурация никем из разработчиков специально не тестируется).
К распаралеливаемости это всё не имеет ни малейшего отношения.
На 64-битном ядре вполне себе может работать полностью 32-битный userpace. Только это может не поддерживаться дистрибутивом (например, насколько я знаю, Debian не поддерживает; не в смысле что не работает, а в смысле что такая конфигурация никем из разработчиков специально не тестируется).
К распаралеливаемости это всё не имеет ни малейшего отношения.
Имеет. Грубо, очень грубо говоря, приложение, использующее ia32-libs, используют одно ядро.
>ia32-libs нужны, когда у вас userspace 64-битный…
К чему данный текст? Я про это и написал.
>ia32-libs нужны, когда у вас userspace 64-битный…
К чему данный текст? Я про это и написал.
Два ядра используется. Только что проверил.
> К чему данный текст? Я про это и написал.
Если у вас на 64-битном ядре стоит 32-битный userspace, ia32-libs не нужны.
> К чему данный текст? Я про это и написал.
Если у вас на 64-битном ядре стоит 32-битный userspace, ia32-libs не нужны.
Спасибо, К.О.
Я даже вижу как вы проверяли: включили приложение, посмотрели состояние процессора.
Для «чистоты» эксперимента необходимо выключить все процессы системы, даже все ваши, как я предполагаю, explorer'ы.
Т.е. нужна чистая модель в вакууме. Тогда вы увидите что грузится только одно ядро.
Но, увы, такой чистоты не добиться.
Поэтому стоит немного погуглить чтобы не говорить глупость.
Я даже вижу как вы проверяли: включили приложение, посмотрели состояние процессора.
Для «чистоты» эксперимента необходимо выключить все процессы системы, даже все ваши, как я предполагаю, explorer'ы.
Т.е. нужна чистая модель в вакууме. Тогда вы увидите что грузится только одно ядро.
Но, увы, такой чистоты не добиться.
Поэтому стоит немного погуглить чтобы не говорить глупость.
А причем тут распараллеливание и 32/64 бита? У меня машинка есть с 64-бит процессором и одним ядром, что и как у меня должно паралеллиться/непараллелиться, чтобы я ощутил достоинства/недостатки 64 бит?
Тут явно надо не сервер мучить а вас — У меня в среднем 18 метров на процес
Вопрос номер два — как вы ходите на 8ми ядрах запускать более 20 процесов апача?
Поясняю — чем больше процесов тем больше они друг другу мешают.
Раз тебе мешают — ты выполняешься дольше. А в итоге получаем больше активных процесов.
Server down
Я бы сделал сервер лимит в 16 чтук.
Вопрос номер два — как вы ходите на 8ми ядрах запускать более 20 процесов апача?
Поясняю — чем больше процесов тем больше они друг другу мешают.
Раз тебе мешают — ты выполняешься дольше. А в итоге получаем больше активных процесов.
Server down
Я бы сделал сервер лимит в 16 чтук.
Мне не мешают. Все как работало, так и работает. 20 процессов? У меня на 2Гб памяти работало 50 и сервер прекрасно себя чувствовал.
Чем они мешают друг другу? :-) Если так, давайте оставим один процесс, который точно никому не будет мешать.
Чем они мешают друг другу? :-) Если так, давайте оставим один процесс, который точно никому не будет мешать.
На переключение процессов также требуется процессорное время. Больше процессов — больше накладных расходов на управление мим. Увеличивать число апачей имеет смысл если большую часть времени они проводят в ожидании ввода-вывода а не в активной обработке данных. Чаще всего происходит это из-за медленных клиентов, забирающих контент с сервера через унылый диалап (все это время процесс апача будет занят и не сможет обрабатывать другие запросы). Однако есть более эффективный способ — ставить легкий кеширующий прокси перед пулом апачей, в этом случае апач быстро отдаст контент в прокси и станет доступен для новых запросов, а прокси уже будет раздавать данные с минимальными накладными расходами.
Выводы: 16 — 20 апачей + nginx
Выводы: 16 — 20 апачей + nginx
у меня логичный вопрос, у вас программы состоят из одних указателей?
для моей системы разница была на 20% памяти между 32 и 64.
для моей системы разница была на 20% памяти между 32 и 64.
У меня было несколько случаев, когда потребовалось более 6GB на процесс. Вариантов кроме 64бит соотв. не было. Впрочем это специальные задачи, для обычного хостинга (который тут в комментариях обсуждается) лучше (имхо) использовать 32bit системы, они надежнее, патчей больше, позволяют использовать гораздо больше 4GB оперативной памяти (на один процесс больше 3.5GB не выделить, но процессов может быть много).
По поводу «Вариантов кроме 64бит соотв. не было» — есть способы на 32bit windows:
blogs.msdn.com/oldnewthing/archive/2009/07/06/9818299.aspx
blogs.msdn.com/oldnewthing/archive/2009/07/06/9818299.aspx
А есть уверенность, что процесс потребляет именно столько памяти, а не в 10 раз меньше?
Столбик RES в top'e — показатель уверенности?
Да что вы все к указателям прицепились? — ВСЕ переменные, как правило, выравниваются по длине машинного слова. Тот же всеми любимый integer будет занимать 8 байт, а не 4.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
А я глупый начал с 64 не подозревая о подвохе, постоянно хаял эту убунту (под конц дня занято вся память + гиг свопа), перешел на 32 и все летает, своп вообще не используется (при том же наборе софта). В общем 64 существует для того чтобы было место удивлению при переходе на 32 :)
>рост потребления памяти обусловлен вдвое большей длиной указателей.
и сколько суммарно занимают все указатели в программе — 5кб? 10?
не бывает таких программ, у которых из 50мб занятой памяти 95% — указатели
и сколько суммарно занимают все указатели в программе — 5кб? 10?
не бывает таких программ, у которых из 50мб занятой памяти 95% — указатели
автор, зачем тебе 64бита на 4гб? оно нужно когда появляются процессы которым нужно адресовать больше 4гб, а это вряд ли тот случай. 4-8-16-32гб — нет особого смысла в 64бит ос (кроме описанного).
х86_64 в нашем случае это в первую очередь маркетинг.
х86_64 в нашем случае это в первую очередь маркетинг.
Вообще 2 кратного роста потребления памяти я не замечал. Довольно странно. Указатели все таки это не весь код. Возможно в апаче используется много типов вроде size_t. Кроме возможности адресовать больше памяти, вообще должны быстрее выполняться 64х битные операции, тк код компилятор будет генерить зная о 64х битных регистрах. Регистров стало около 100 штук, что позволяет процессору генерить более эффективое внеочередное выполнение команд, тк возможностей переименовывания регистров больше. Думаю так же всегда происходит компиляция с поддержкой SEE. Короче плюсов масса. Из реально наблюдаемых стал значительно шустрее работать mysql. Сравнением выполнения своих программ я не занимался, но по памяти не сильная разница, думаю 30% верхних предел. Возможно в программах где кучи указателей и кода и мало данных разница будет больше. Плюсов на самом деле больше. Это только то что я вспомнил.
я тоже выбрал в качестве десктопа 64 битную убунту
каких только лапшей и пугал мне не предлагали
всё гон! все работает и работает шустро
нет никаких «в 2 раза потребление памяти больше» «мало 64 битных прог»
всем рекомендую быстрее переходить на 64битную версию любимой ОСи, при аппаратной возможности
каких только лапшей и пугал мне не предлагали
всё гон! все работает и работает шустро
нет никаких «в 2 раза потребление памяти больше» «мало 64 битных прог»
всем рекомендую быстрее переходить на 64битную версию любимой ОСи, при аппаратной возможности
А апач на новой операционке собран прям точь в точь как и на старой и все конфиги старые? Может там версия апача другая, модули другие, версии модулей другие, конфиг другой.
Уточню, что на самом деле меня заботит не столько вопрос про количество дочек Apache в памяти, сколько ресурсы потребляемые PHP.
Например, до переезда разрабатываемый мною движок cogear потреблял в среднем 1.2Мб на одну страницу, а после стал потреблять в среднем 2.4Мб.
Настройки PHP одинаковые. ZendOptimizer + eAccelerator + IONCube Loader.
Например, до переезда разрабатываемый мною движок cogear потреблял в среднем 1.2Мб на одну страницу, а после стал потреблять в среднем 2.4Мб.
Настройки PHP одинаковые. ZendOptimizer + eAccelerator + IONCube Loader.
Все почему-то забывают, что кроме этой замечательной адресации >4 Гб, 64х битный процессор может производить операции над 4х байтовыми величинами за один такт, а 32х битный за два. Сюда относятся все расчеты высокой точности и все оптимизированные алгоритмы сжатия, хеширования, шифровки.
Выигрыш в том, что больше не надо думать о лимитах памяти. Это, собственно, основной выигрыш, но по мощности сравнимый с переходом с Win16 на Win32. Конечно, есть дополнительные оптимизации, но главное — это именно расширение плоского адресного пространства за границу в 4 Гб. Это ОЧЕНЬ существенно влияет, например, на файловые кэши ОС, на раскидывание процессов по памяти… разумеется, если у вас памяти больше 4 Гб. Если меньше — можно оставаться на 32 битах.
Что касается апачей — то да, софт обычно распухает примерно вдвое из-за того, что стандартные типы (инты в основном) теперь 64-битные, и выравнивание данных тоже 64-битное. Но, во-первых, вы теперь можете ставить больше памяти:) (я понимаю, слабое утешение), а во-вторых, вам не нужно столько апачей.
Это мантра такая, её надо повторять: мне не нужно столько апачей. Поставьте фронтендом nginx, отдавайте через него статику, а апачу оставьте только динамику. Потребление памяти упадёт В РАЗЫ. И сразу.
Что касается апачей — то да, софт обычно распухает примерно вдвое из-за того, что стандартные типы (инты в основном) теперь 64-битные, и выравнивание данных тоже 64-битное. Но, во-первых, вы теперь можете ставить больше памяти:) (я понимаю, слабое утешение), а во-вторых, вам не нужно столько апачей.
Это мантра такая, её надо повторять: мне не нужно столько апачей. Поставьте фронтендом nginx, отдавайте через него статику, а апачу оставьте только динамику. Потребление памяти упадёт В РАЗЫ. И сразу.
А если нет специфичных задач требующих именно апача, то можно и без него совсем (php-fpm + nginx).
Да ведь не вся память, занимаемая процессом, состоит из распухших в 2 раза интов и поинтеров. Максимум их там наберется процентов 5%. Остальное — кэш, данные, текст всякий — будет потреблять ровно столько же памяти.
Ну вот откуда Вы взяли эти 5%? С потолка?
Мне, на самом деле, не очень интересно, что там на самом деле пухнет. Медицинский факт состоит в том, что apache+php распухает на 64 битах примерно вдвое. И это повод отказаться от апача как минимум на раздаче статики.
Мне, на самом деле, не очень интересно, что там на самом деле пухнет. Медицинский факт состоит в том, что apache+php распухает на 64 битах примерно вдвое. И это повод отказаться от апача как минимум на раздаче статики.
Я говорю о том, что вероятность распухания приложения примерно вдвое стремится к нулю. Для этого оно должно работать только и исключительно с переменными int и pointer. В подавляющем же большинстве случаев объем, занимаемый этими типами ничтожно мал. Видится мне, просто потребление памяти измеряли неправильно.
Например, вместо использования ps попробуйте посмотреть в pmap использование памяти. Исключите все shared libraries (которые, да, на х64 потребляют памяти больше, но не забудьте, что они загружены в память один раз, а ps их приплюсовывает к каждому экземпляру процесса). И теперь сравните реальные цифры чистого потребления памяти апачем на 32 и 64.
Например, вместо использования ps попробуйте посмотреть в pmap использование памяти. Исключите все shared libraries (которые, да, на х64 потребляют памяти больше, но не забудьте, что они загружены в память один раз, а ps их приплюсовывает к каждому экземпляру процесса). И теперь сравните реальные цифры чистого потребления памяти апачем на 32 и 64.
Я уже не смогу этого сделать, от Апача я отказался лет пять назад:) Если автор топика проверит — будет интересно.
Я помню, что смотрел по-простому, top-ом. И значения, которые я видел около процессов, подозрительным образом соответствовали уменьшению доступной памяти.
Я помню, что смотрел по-простому, top-ом. И значения, которые я видел около процессов, подозрительным образом соответствовали уменьшению доступной памяти.
Очевидно, сие относится к любым процессам, апач я упомянул только потому что он был упомянут автором топика.
pastebin.com/m1dcf638b — можете расшифровать? Это вывод pmap на php-процессе, “grep -v '.so'” исключает из вывода shared либы.
170 / 30 Мб внизу — это то, что показывают и top и ps. А как надо читать на самом деле?
170 / 30 Мб внизу — это то, что показывают и top и ps. А как надо читать на самом деле?
Добро пожаловать в мир 64 разрядов=)))
>>Знающие люди подсказали то, о чем сразу не подумал сам — рост потребления памяти обусловлен вдвое большей длиной указателей.
не понял, как размер указателя влияет на объём памяти, который он адресует? Вообще тема интересная почему так происходит, хотелось бы почитать технические статьи на эту тему.
не понял, как размер указателя влияет на объём памяти, который он адресует? Вообще тема интересная почему так происходит, хотелось бы почитать технические статьи на эту тему.
> стали потреблять вдвое больше памяти.
Прямо таки вдвое? )
Прямо таки вдвое? )
скажите, а что вам мешает запускать 32битные программы на 64битной системе если уж вы так нервничаете по увеличению потребляемой памяти. ну и двойное потребление — это явное преувеличение :(
Про всех сложно рассуждать, но у нас выигрыш вполне ощутимый и выгода от 64 бит — прямая и материальная.
Дело в том, что мы сдаем каждому своему клиенту по виртуальному серверу с настроенным окружением. Каждый такой сервер требует около 600Мб оперативной памяти. Загрузка процессора — невысокая.
Так вот. Если использовать на хосте 32 битную ОС, то на одном компьютере можно использовать не более 4Гб RAM и разместить не более 5 клиентов. Если же на хосте установить 64 битную ОС и поставить 8 Гб RAM, то железо обойдется всего на 20% дороже, при том, что количество клиентов, размещаемых на одном хосте увеличивается до 10-12. Соответственно, срок окупаемости у такой конфигурации гораздо меньше.
Дело в том, что мы сдаем каждому своему клиенту по виртуальному серверу с настроенным окружением. Каждый такой сервер требует около 600Мб оперативной памяти. Загрузка процессора — невысокая.
Так вот. Если использовать на хосте 32 битную ОС, то на одном компьютере можно использовать не более 4Гб RAM и разместить не более 5 клиентов. Если же на хосте установить 64 битную ОС и поставить 8 Гб RAM, то железо обойдется всего на 20% дороже, при том, что количество клиентов, размещаемых на одном хосте увеличивается до 10-12. Соответственно, срок окупаемости у такой конфигурации гораздо меньше.
Я на 64-х разрядной машине не вижу 50 мегабайт на апач, а вижу как и раньше, на 32-х разрядной, 15-20. Может быть, всё обсуждение построено на неправильных предпосылках? И аргумент о вдвое большем указателе и выравнивании никакой критики не выдерживает.
сравнивал кодирование lame.
32х битный бинарник под 32х битной осью оказался даже быстрее на несколько процентов
32х битный бинарник под 32х битной осью оказался даже быстрее на несколько процентов
Мне кажется, что в программе, которая только и делает, что работает со строками, будет столько возросшее количество занимаемой памяти. Я почти полностью уверен, что дело в переходе с ubuntu на debian. Отключите ненужные модули, почитайте man о mpm и сделайте новый, улучшенный замер.
ЗЫ. А вообще, если так дорога память — переходите на nginx+php-fpm. 150 воркеров в 2гб памяти помещаются спокойно. RES eу каждого — 10-20mb на 64битной машине,
ЗЫ. А вообще, если так дорога память — переходите на nginx+php-fpm. 150 воркеров в 2гб памяти помещаются спокойно. RES eу каждого — 10-20mb на 64битной машине,
root 728 0.0 0.3 98012 2556? Ss Oct22 0:15 /usr/sbin/apache2 -D SUPHP
apache 730 0.0 0.3 102792 2692? S Oct22 0:00 \_ /usr/sbin/apache2 -D SUPHP
-=>> file /usr/sbin/apache2
/usr/sbin/apache2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
-=>> top -n 1 | grep "^Mem:"
Mem: 716800k total, 8696k used, 708104k free, 0k buffers
-=>> uname -a
Linux host 2.6.27-vmin64 #3 SMP Thu Oct 22 19:34:07 MSD 2009 x86_64 Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
— Апач собран с mpm-prefork, дистр gentoo, виртуалки ovz.
Запущен 1 форк, макс форков до 40.
Если отдавать nginx всю статику, то апач форкается только для пхп с перлом, это 2-5мб форк апача + 15-30мб php-cgi
— Если использовать только nginx + fpm, то в этом случае памяти будет использоваться больше, в зависимости от форков php-cgi. Обычно для одного проекта достаточно около 3-5 форков php-cgi, это примерно по 15-30мбайт физ. памяти на 1 форк.
Вот и считайте…
В первом варианте с apache используется динамическое выделение ресурсов, а во втором варианте ресурсы выделяются в максимальном кол-ве сразу.
P.P
apache 730 0.0 0.3 102792 2692? S Oct22 0:00 \_ /usr/sbin/apache2 -D SUPHP
-=>> file /usr/sbin/apache2
/usr/sbin/apache2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
-=>> top -n 1 | grep "^Mem:"
Mem: 716800k total, 8696k used, 708104k free, 0k buffers
-=>> uname -a
Linux host 2.6.27-vmin64 #3 SMP Thu Oct 22 19:34:07 MSD 2009 x86_64 Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux
— Апач собран с mpm-prefork, дистр gentoo, виртуалки ovz.
Запущен 1 форк, макс форков до 40.
Если отдавать nginx всю статику, то апач форкается только для пхп с перлом, это 2-5мб форк апача + 15-30мб php-cgi
— Если использовать только nginx + fpm, то в этом случае памяти будет использоваться больше, в зависимости от форков php-cgi. Обычно для одного проекта достаточно около 3-5 форков php-cgi, это примерно по 15-30мбайт физ. памяти на 1 форк.
Вот и считайте…
В первом варианте с apache используется динамическое выделение ресурсов, а во втором варианте ресурсы выделяются в максимальном кол-ве сразу.
P.P
По идее операции блочной пересылки на 64 битах должны выполняться быстрее. Но я видел бенчмарки с 64 и 32 битными линуксами — результаты неоднозначные.
Немного не в тему, в Java 7 добавили compressed pointers. То есть все указатели из 64 битных внутренне сжимаются в 32-битные, что очень экономит память.
Немного не в тему, в Java 7 добавили compressed pointers. То есть все указатели из 64 битных внутренне сжимаются в 32-битные, что очень экономит память.
Давным давно уже рост производительности процессоров и прочая физическая прокачка перестала играть главную роль в результате с т.з. пользователя и программы. Люди реализуют бизнес-логику увешанную графикой, никто не программирует по-настоящему, не осваивает возможности железа, и не оптимизирует алгоритмы — поэтому мы и на 16-ти ядерных процессорах, будем чегото постоянно ждать, наблюдая в ожидании занятные фрактальные или 3дэшные финтифлюшки…
Что-то я такого не замечал: у меня что дома (арч, 64бит), что на работе (мандрива, 32бит) огнелис жрет 1.5-2ГБ оперативки; остальные процессы едят тоже примерно одинаково. Разницы в потреблении оперативки не замечал (IceWM все так же ест ~10МБ, geany с одинаковыми открытыми файлами — все те же ~15МБ…), зато налицо явный прирост производительности.
Sign up to leave a comment.
64 vs 32 — в чем выигрыш?