<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр / Комментарии к посту «64 vs 32 — в чем выигрыш?» в блоге «Серверная оптимизация»</title>
	<link>http://habrahabr.ru/rss/post/75229/</link>
	<description><![CDATA[Новые комментарии к посту «64 vs 32 — в чем выигрыш?» в блоге «Серверная оптимизация»]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Sat, 11 Feb 2012 17:07:51 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	

	
	
	
	
	
		
	
		<item>
			<title>13.12.2011 13:02:47 Eddy_Em</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_4467602</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_4467602</link>
			<description><![CDATA[Что-то я такого не замечал: у меня что дома (арч, 64бит), что на работе (мандрива, 32бит) огнелис жрет 1.5-2ГБ оперативки; остальные процессы едят тоже примерно одинаково. Разницы в потреблении оперативки не замечал (IceWM все так же ест ~10МБ, geany с одинаковыми открытыми файлами — все те же ~15МБ…), зато налицо явный прирост производительности.]]></description>
			<pubDate>Tue, 13 Dec 2011 13:02:47 GMT</pubDate>
			<author>Eddy_Em</author>
		</item>
	

	
		<item>
			<title>13.12.2011 12:52:23 rdc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_4467573</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_4467573</link>
			<description><![CDATA[Никто не мешает гонять 32bit софт на 64bit системе. Что позволяет и поддерживать системой любой объём RAM, и снизить затраты оперативы софтом.]]></description>
			<pubDate>Tue, 13 Dec 2011 12:52:23 GMT</pubDate>
			<author>rdc</author>
		</item>
	

	
		<item>
			<title>05.04.2010 16:41:06 Semy</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2706951</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2706951</link>
			<description><![CDATA[костыль.]]></description>
			<pubDate>Mon, 05 Apr 2010 16:41:06 GMT</pubDate>
			<author>Semy</author>
		</item>
	

	
		<item>
			<title>05.04.2010 12:39:15 shiko_1st</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2705820</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2705820</link>
			<description><![CDATA[Ну а как еще им именовать архитектуру, разработанную конкурентом и прямо бьющую по никому не нужным итаникам? Они, помнится, еще и письма рассылали — что AMD64 это не настоящие 64 бита.]]></description>
			<pubDate>Mon, 05 Apr 2010 12:39:15 GMT</pubDate>
			<author>shiko_1st</author>
		</item>
	

	
		<item>
			<title>17.12.2009 16:24:12 mkevac</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2294126</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2294126</link>
			<description><![CDATA[Linux dls17 2.6.22.5-31-bigsmp #1 SMP 2007/09/21 22:29:00 UTC i686 i686 i386 GNU/Linux<br/>
]]></description>
			<pubDate>Thu, 17 Dec 2009 16:24:12 GMT</pubDate>
			<author>mkevac</author>
		</item>
	

	
		<item>
			<title>17.12.2009 16:17:11 jcmvbkbc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2294103</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2294103</link>
			<description><![CDATA[<a href="http://ptgmedia.pearsoncmg.com/images/0131453483/downloads/gorman_book.pdf">ptgmedia.pearsoncmg.com/images/0131453483/downloads/gorman_book.pdf</a><br/>
<br/>
Пункт 2.7 этой книжки немного объясняет в чём дело. А какое же у вас ядро?]]></description>
			<pubDate>Thu, 17 Dec 2009 16:17:11 GMT</pubDate>
			<author>jcmvbkbc</author>
		</item>
	

	
		<item>
			<title>17.11.2009 10:45:37 Sap_ru</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2188516</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2188516</link>
			<description><![CDATA[Да, я уже успел вдумчиво изучить спецификацию x64 — не требует она никакого специфичного выравнивания данных. И регистры там 32 бита (указатели 64 бита). Единственный грабель — множество регистров общего назначения, которые нужно сохранять в стеке при вызове подпрограмм, но эта проблема давно и успешно решена на множестве RISC-архитектур. Т.е. правильно написанная программа должна отличаться на проценты по потреблению памяти. Откуда такой перерасход категорически не понятно. Подозреваю кривые руки программистов и/или грандиозные глюки компиляторов.]]></description>
			<pubDate>Tue, 17 Nov 2009 10:45:37 GMT</pubDate>
			<author>Sap_ru</author>
		</item>
	

	
		<item>
			<title>16.11.2009 14:50:22 michaek</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2186062</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2186062</link>
			<description><![CDATA[можно мигрировать на 32-битную систему, но проще и быстрее переставить]]></description>
			<pubDate>Mon, 16 Nov 2009 14:50:22 GMT</pubDate>
			<author>michaek</author>
		</item>
	

	
		<item>
			<title>16.11.2009 06:42:03 etz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2184558</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2184558</link>
			<description><![CDATA[Делать выбор апач или nginx нужно осмысленно. пхп тут практически не при чём.]]></description>
			<pubDate>Mon, 16 Nov 2009 06:42:03 GMT</pubDate>
			<author>etz</author>
		</item>
	

	
		<item>
			<title>15.11.2009 14:43:50 Losted</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182946</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182946</link>
			<description><![CDATA[в x64 physx под вайном не ставится ;)]]></description>
			<pubDate>Sun, 15 Nov 2009 14:43:50 GMT</pubDate>
			<author>Losted</author>
		</item>
	

	
		<item>
			<title>15.11.2009 13:55:42 Siddthartha</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182796</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182796</link>
			<description><![CDATA[Давным давно уже рост производительности процессоров и прочая физическая прокачка перестала играть главную роль в результате с т.з. пользователя и программы. Люди реализуют бизнес-логику увешанную графикой, никто не программирует по-настоящему, не осваивает возможности железа, и не оптимизирует алгоритмы — поэтому мы и на 16-ти ядерных процессорах, будем чегото постоянно ждать, наблюдая в ожидании занятные фрактальные или 3дэшные финтифлюшки…]]></description>
			<pubDate>Sun, 15 Nov 2009 13:55:42 GMT</pubDate>
			<author>Siddthartha</author>
		</item>
	

	
		<item>
			<title>15.11.2009 13:05:03 Throwable</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182657</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182657</link>
			<description><![CDATA[По идее операции блочной пересылки на 64 битах должны выполняться быстрее. Но я видел бенчмарки с 64 и 32 битными линуксами — результаты неоднозначные.<br/>
<br/>
Немного не в тему, в Java 7 добавили compressed pointers. То есть все указатели из 64 битных внутренне сжимаются в 32-битные, что очень экономит память.]]></description>
			<pubDate>Sun, 15 Nov 2009 13:05:03 GMT</pubDate>
			<author>Throwable</author>
		</item>
	

	
		<item>
			<title>15.11.2009 13:00:54 zhuk</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182644</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182644</link>
			<description><![CDATA[ушел читать про OOM Killer]]></description>
			<pubDate>Sun, 15 Nov 2009 13:00:54 GMT</pubDate>
			<author>zhuk</author>
		</item>
	

	
		<item>
			<title>15.11.2009 12:40:50 VolCh</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182591</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182591</link>
			<description><![CDATA[Я в свое время тоже так думал, пока не понял, что основные траблы с памятью у меня из-за флэша на открытых страницах.]]></description>
			<pubDate>Sun, 15 Nov 2009 12:40:50 GMT</pubDate>
			<author>VolCh</author>
		</item>
	

	
		<item>
			<title>15.11.2009 12:35:57 VolCh</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182583</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182583</link>
			<description><![CDATA[А причем тут распараллеливание и 32/64 бита? У меня машинка есть с 64-бит процессором и одним ядром, что и как у меня должно паралеллиться/непараллелиться, чтобы я ощутил достоинства/недостатки 64 бит?]]></description>
			<pubDate>Sun, 15 Nov 2009 12:35:57 GMT</pubDate>
			<author>VolCh</author>
		</item>
	

	
		<item>
			<title>15.11.2009 11:46:20 Pavel_Pronskiy</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182477</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182477</link>
			<description><![CDATA[root 728 0.0 0.3 98012 2556? Ss Oct22 0:15 /usr/sbin/apache2 -D SUPHP<br/>
apache 730 0.0 0.3 102792 2692? S Oct22 0:00 \_ /usr/sbin/apache2 -D SUPHP<br/>
<br/>
-=&gt;&gt; file /usr/sbin/apache2<br/>
/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<br/>
<br/>
-=&gt;&gt; top -n 1 | grep &quot;^Mem:&quot;<br/>
Mem: 716800k total, 8696k used, 708104k free, 0k buffers<br/>
<br/>
-=&gt;&gt; uname -a<br/>
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<br/>
<br/>
 — Апач собран с mpm-prefork, дистр gentoo, виртуалки ovz.<br/>
Запущен 1 форк, макс форков до 40.<br/>
Если отдавать nginx всю статику, то апач форкается только для пхп с перлом, это 2-5мб форк апача + 15-30мб php-cgi<br/>
<br/>
 — Если использовать только nginx + fpm, то в этом случае памяти будет использоваться больше, в зависимости от форков php-cgi. Обычно для одного проекта достаточно около 3-5 форков php-cgi, это примерно по 15-30мбайт физ. памяти на 1 форк.<br/>
<br/>
Вот и считайте…<br/>
В первом варианте с apache используется динамическое выделение ресурсов, а во втором варианте ресурсы выделяются в максимальном кол-ве сразу.<br/>
<br/>
<b>P.P</b><br/>
]]></description>
			<pubDate>Sun, 15 Nov 2009 11:46:20 GMT</pubDate>
			<author>Pavel_Pronskiy</author>
		</item>
	

	
		<item>
			<title>15.11.2009 11:35:44 borisko</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182454</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182454</link>
			<description><![CDATA[Мне кажется, что в программе, которая только и делает, что работает со строками, будет столько возросшее количество занимаемой памяти. Я почти полностью уверен, что дело в переходе с ubuntu на debian. Отключите ненужные модули, почитайте man о mpm и сделайте новый, улучшенный замер.<br/>
<br/>
ЗЫ. А вообще, если так дорога память — переходите на nginx+php-fpm. 150 воркеров в 2гб памяти помещаются спокойно. RES eу каждого — 10-20mb на 64битной машине, ]]></description>
			<pubDate>Sun, 15 Nov 2009 11:35:44 GMT</pubDate>
			<author>borisko</author>
		</item>
	

	
		<item>
			<title>15.11.2009 09:09:40 Lotares</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182167</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182167</link>
			<description><![CDATA[Почему, вполне может быть больше двух — смонтированное.]]></description>
			<pubDate>Sun, 15 Nov 2009 09:09:40 GMT</pubDate>
			<author>Lotares</author>
		</item>
	

	
		<item>
			<title>15.11.2009 08:18:59 D_E_N_I_S_K_A</title>
			<guid isPermaLink="true">#comment_2182093</guid>
			<link>#comment_2182093</link>
			<description><![CDATA[i386 — 80386 и более поздние.<br/>
i686 — Pentium Pro и более поздние.]]></description>
			<pubDate>Sun, 15 Nov 2009 08:18:59 GMT</pubDate>
			<author>D_E_N_I_S_K_A</author>
		</item>
	

	
		<item>
			<title>15.11.2009 07:33:09 M_org</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182059</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182059</link>
			<description><![CDATA[Ну, если так — то да. У меня просто возникает подозрение, что конвертация DV Video (по идее, оно не должно быть больше 2 часов?) будет занимать 100 часов :) Хотя все бывает.]]></description>
			<pubDate>Sun, 15 Nov 2009 07:33:09 GMT</pubDate>
			<author>M_org</author>
		</item>
	

	
		<item>
			<title>15.11.2009 06:40:03 dobersoft</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182014</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2182014</link>
			<description><![CDATA[сравнивал кодирование lame.<br/>
32х битный бинарник под 32х битной осью оказался даже быстрее на несколько процентов]]></description>
			<pubDate>Sun, 15 Nov 2009 06:40:03 GMT</pubDate>
			<author>dobersoft</author>
		</item>
	

	
		<item>
			<title>15.11.2009 01:52:28 John_Minority</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181896</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181896</link>
			<description><![CDATA[Не путайте<br/>
i386 — pentium pro<br/>
i686 — последнии перед x86_64 пни и атлоны!]]></description>
			<pubDate>Sun, 15 Nov 2009 01:52:28 GMT</pubDate>
			<author>John_Minority</author>
		</item>
	

	
		<item>
			<title>15.11.2009 01:45:05 thebird</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181893</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181893</link>
			<description><![CDATA[да. разницу лучше мерять в процентах а не в часах<br/>
]]></description>
			<pubDate>Sun, 15 Nov 2009 01:45:05 GMT</pubDate>
			<author>thebird</author>
		</item>
	

	
		<item>
			<title>14.11.2009 23:54:12 Lotares</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181823</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181823</link>
			<description><![CDATA[Ну всё относительно. Может у человека проект на 32х-битной системе рендерится 101.5 часов, а на 64х — ровно 100. =)]]></description>
			<pubDate>Sat, 14 Nov 2009 23:54:12 GMT</pubDate>
			<author>Lotares</author>
		</item>
	

	
		<item>
			<title>14.11.2009 21:28:00 M_org</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181581</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181581</link>
			<description><![CDATA[Просто мне внушает подозрение разница в полтора часа. Разумеется, я знаю что 64 битная архитектура может дать прирост в производительности. Но не в такой же степени?!?]]></description>
			<pubDate>Sat, 14 Nov 2009 21:28:00 GMT</pubDate>
			<author>M_org</author>
		</item>
	

	
		<item>
			<title>14.11.2009 20:26:06 thebird</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181391</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181391</link>
			<description><![CDATA[Проблемы с оптимизацией какраз могут быть на x64, но это опять же стереотип, живший в головах несколко лет назад. Сейчас уже научились писать нормальные приложения адекватно оперирующие 64 разрядами.]]></description>
			<pubDate>Sat, 14 Nov 2009 20:26:06 GMT</pubDate>
			<author>thebird</author>
		</item>
	

	
		<item>
			<title>14.11.2009 19:24:56 mkevac</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181284</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181284</link>
			<description><![CDATA[В дополнение к предыдущему комментарию, чтобы не думали что я теорией тут занимаюсь. Данное поведение замечено на наших 8 серваках с 32 GiB памяти. Срочно меняем систему на 64-битную.<br/>
<br/>
Единственное из упоминаний этого феномена нашли на <a href="http://www.linux-mm.org/">www.linux-mm.org/</a><br/>
<br/>
Проблема временно решается сбрасыванием дисковых кэшей. Но помогает ненадолго. Как-только LowMem кончается начинает свою грязную работу OOM killer. При этом HighMem даже на половину не занят.]]></description>
			<pubDate>Sat, 14 Nov 2009 19:24:56 GMT</pubDate>
			<author>mkevac</author>
		</item>
	

	
		<item>
			<title>14.11.2009 19:20:36 mkevac</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181271</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181271</link>
			<description><![CDATA[OOM killer на 32-битной архитектуре убивает процессы, когда кончается HighMem или LowMem. В случае использования более чем 16 GiB (32 GiB) под 32-битным PAE LowMem заполняется за день-два средней нагрузки, после чего OOM killer начинает убивать процессы. Что в конце концов приводит к смерти системы.<br/>
<br/>
При ограничении памяти до 16GiB LowMem не забивается и OOM не вызывается. При 32 GiB забивается за 2 дня.]]></description>
			<pubDate>Sat, 14 Nov 2009 19:20:36 GMT</pubDate>
			<author>mkevac</author>
		</item>
	

	
		<item>
			<title>14.11.2009 19:11:21 david_mz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181254</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181254</link>
			<description><![CDATA[Ага, спасибо.<br/>
<br/>
Но с 32-мя я уже сравнить не смогу.]]></description>
			<pubDate>Sat, 14 Nov 2009 19:11:21 GMT</pubDate>
			<author>david_mz</author>
		</item>
	

	
		<item>
			<title>14.11.2009 19:03:13 jcmvbkbc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181244</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181244</link>
			<description><![CDATA[OOM killer убивает только процессы. И то не любые. И делает это, когда кончается виртуальная память.<br/>
Как это связано с PAE, 16GiB и LowMem?]]></description>
			<pubDate>Sat, 14 Nov 2009 19:03:13 GMT</pubDate>
			<author>jcmvbkbc</author>
		</item>
	

	
		<item>
			<title>14.11.2009 19:02:05 lashtal</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181240</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181240</link>
			<description><![CDATA[именно. и данное значение следует брать в сравнении 32 v 64.]]></description>
			<pubDate>Sat, 14 Nov 2009 19:02:05 GMT</pubDate>
			<author>lashtal</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:58:36 jcmvbkbc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181234</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181234</link>
			<description><![CDATA[9976kb — чистый вклад этого процесса в использованную память.]]></description>
			<pubDate>Sat, 14 Nov 2009 18:58:36 GMT</pubDate>
			<author>jcmvbkbc</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:53:40 jcmvbkbc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181223</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181223</link>
			<description><![CDATA[/proc/PID/smaps, парсер лох]]></description>
			<pubDate>Sat, 14 Nov 2009 18:53:40 GMT</pubDate>
			<author>jcmvbkbc</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:52:20 jcmvbkbc</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181217</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181217</link>
			<description><![CDATA[Столбик RES говорит сколько виртуальной памяти процесса в настоящий момент находится в физической памяти.<br/>
<br/>
Показатель уверенности — как ни странно, VIRT в top'е, или private_dirty+swap в /proc//smaps]]></description>
			<pubDate>Sat, 14 Nov 2009 18:52:20 GMT</pubDate>
			<author>jcmvbkbc</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:48:16 enjoint</title>
			<guid isPermaLink="true">#comment_2181207</guid>
			<link>#comment_2181207</link>
			<description><![CDATA[У тебя завышенная самооценка. Посмотри на самый первый комментарий.]]></description>
			<pubDate>Sat, 14 Nov 2009 18:48:16 GMT</pubDate>
			<author>enjoint</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:46:23 akalend</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181202</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181202</link>
			<description><![CDATA[лидер среди минусов!]]></description>
			<pubDate>Sat, 14 Nov 2009 18:46:23 GMT</pubDate>
			<author>akalend</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:39:01 david_mz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181191</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181191</link>
			<description><![CDATA[<a href="http://pastebin.com/m1dcf638b">pastebin.com/m1dcf638b</a> — можете расшифровать? Это вывод pmap на php-процессе, “grep -v '.so'” исключает из вывода shared либы.<br/>
<br/>
170 / 30 Мб внизу — это то, что показывают и top и ps. А как надо читать на самом деле?]]></description>
			<pubDate>Sat, 14 Nov 2009 18:39:01 GMT</pubDate>
			<author>david_mz</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:14:51 lashtal</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181143</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181143</link>
			<description><![CDATA[Очевидно, сие относится к любым процессам, апач я упомянул только потому что он был упомянут автором топика.]]></description>
			<pubDate>Sat, 14 Nov 2009 18:14:51 GMT</pubDate>
			<author>lashtal</author>
		</item>
	

	
		<item>
			<title>14.11.2009 18:09:24 david_mz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181129</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181129</link>
			<description><![CDATA[Я уже не смогу этого сделать, от Апача я отказался лет пять назад:) Если автор топика проверит — будет интересно.<br/>
<br/>
Я помню, что смотрел по-простому, top-ом. И значения, которые я видел около процессов, подозрительным образом соответствовали уменьшению доступной памяти.]]></description>
			<pubDate>Sat, 14 Nov 2009 18:09:24 GMT</pubDate>
			<author>david_mz</author>
		</item>
	

	
		<item>
			<title>14.11.2009 17:27:52 arrowdodger</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181065</guid>
			<link>http://habrahabr.ru/blogs/server_side_optimization/75229/#comment_2181065</link>
			<description><![CDATA[Вы же сами вроде сказали — выравнивание структов.<br/>
Но я не понял вот это:<br/>
&gt;Плюс, стек в два раза разрастается — для сохранения регистров нужно в два раза больше памяти.]]></description>
			<pubDate>Sat, 14 Nov 2009 17:27:52 GMT</pubDate>
			<author>arrowdodger</author>
		</item>
	

	
</channel>
</rss>

