<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Комментарии к записи: &#8220;Возвращаясь к напечатанному&#8221;</title>
	<atom:link href="http://blog.aboutnetapp.ru/archives/1266/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.aboutnetapp.ru/archives/1266</link>
	<description>Системы хранения данных как предмет разговора</description>
	<pubDate>Wed, 07 Apr 2021 12:05:52 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>Автор: romx</title>
		<link>http://blog.aboutnetapp.ru/archives/1266#comment-8626</link>
		<dc:creator>romx</dc:creator>
		<pubDate>Fri, 26 Jul 2013 09:13:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/1266#comment-8626</guid>
		<description>Alexey:
Ждите через неделю большой пост под заголовком: "Что HP думает о NetApp, и как обстоит все на самом деле." :)

А по этим пунктам:
1. Ребята просто читают по диагонали старые доки, при этом владея темой весьма поверхностно. 15% относится не к падению производительности, а к максимально заданному для этой задачи уровню загрузки CPU при работе активного процесса дедупликации в 8 потоков. Так как процесс дедупликации выполняется с пониженным приоритетом, то любой активный процесс ввода-вывода данных, появившись в системе, отберет у него эти процессорные тики. После того, как процесс закончится, дедупликатор вновь получит свои тики, ограниченные сверху 15%.

2. Это, конечно, очень важно для клиентов, у которых данных более 23PB, я знаю, такие каждую неделю приходят за стораджами (/irony)</description>
		<content:encoded><![CDATA[<p>Alexey:<br />
Ждите через неделю большой пост под заголовком: &#8220;Что HP думает о NetApp, и как обстоит все на самом деле.&#8221; :)</p>
<p>А по этим пунктам:<br />
1. Ребята просто читают по диагонали старые доки, при этом владея темой весьма поверхностно. 15% относится не к падению производительности, а к максимально заданному для этой задачи уровню загрузки CPU при работе активного процесса дедупликации в 8 потоков. Так как процесс дедупликации выполняется с пониженным приоритетом, то любой активный процесс ввода-вывода данных, появившись в системе, отберет у него эти процессорные тики. После того, как процесс закончится, дедупликатор вновь получит свои тики, ограниченные сверху 15%.</p>
<p>2. Это, конечно, очень важно для клиентов, у которых данных более 23PB, я знаю, такие каждую неделю приходят за стораджами (/irony)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: Alexey</title>
		<link>http://blog.aboutnetapp.ru/archives/1266#comment-8625</link>
		<dc:creator>Alexey</dc:creator>
		<pubDate>Fri, 26 Jul 2013 09:07:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.aboutnetapp.ru/archives/1266#comment-8625</guid>
		<description>Вот пара фудов от одного из вендоров:

1) При включении хотя бы одного процесса дедупликации (всего параллельно может быть 8) производительность падает на 15%. ПЛюс метаданные съедают 8% емкости раздела.

2) V3200/6200 поддерживают виртуализированный объем не больше пределов FAS 3200/6200. Например, в сумме с учетом кластерного режима V6290 поддерживает только 23 Пб, что все равно меньше 32 Пб поддерживаемой ви7000.</description>
		<content:encoded><![CDATA[<p>Вот пара фудов от одного из вендоров:</p>
<p>1) При включении хотя бы одного процесса дедупликации (всего параллельно может быть 8) производительность падает на 15%. ПЛюс метаданные съедают 8% емкости раздела.</p>
<p>2) V3200/6200 поддерживают виртуализированный объем не больше пределов FAS 3200/6200. Например, в сумме с учетом кластерного режима V6290 поддерживает только 23 Пб, что все равно меньше 32 Пб поддерживаемой ви7000.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
