<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="http://valley.egloos.com/rss/style/style.xsl" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>이글루스 'fragmentation' 태그 최근글</title>
		<link>http://valley.egloos.com/tag/fragmentation</link>
		<description>fragmentation</description>
		<language>ko</language>
		<pubDate>Tue, 09 Aug 2011 16:35:10 +0900</pubDate>
		<generator>Egloos</generator>
		<item>
	<title><![CDATA[구글은 사악한가?]]></title>
	<link>http://biztalk72.egloos.com/5563659</link>
	<guid>http://biztalk72.egloos.com/5563659</guid>
	<description>
	<![CDATA[ 
<img 
				src="http://thumb.egloos.net/100x76/http://pds18.egloos.com/pds/201108/09/15/c0073715_4e40e23c5ae04.jpg"  
				alt="구글은 사악한가?" 
				width="100px"  
				height="76pxpx"
				align="left"
				style="border:1px solid #DDDDDD;margin:0 10px 10px 0px;"
				/> 아..오랫만에 블로그 관리 중...정말 짧은 글 하나 올리려 한다....  처음 구글이 검색을 주 비지니스 모델로 한 포털을 오픈했을때만 해도.... 야후나 인포서치, 네이버, 다음, 한미르 등 다양한 포털들이 이합집산 끝에 하나씩 대형 포털로 합쳐질 즈음이었다. 대형 포털로 합쳐지다 보니 수익원에 대한 갈망은 당연했을 것이고...그러다 보니 '내가 찾고자 하는 검색결과'와 '포털이 보여주고자 하는 검색결과' 사이에는 상당한 갭이 생기고 점점 그 갭은 커져 갔다. 이때 혜성같이 등장한 구글은 정말 엔지니어에게는 최고의 선물과 같았다!  그러던 구글이 점점 커지고 애드워~~~ㄹ즈(AdWords), 애드클릭 등의 CPC 기반 광고와 연동될 때까지도 구글은 정말 착해 보였다. 구글의 슬로건이 &quot;Don't be E	]]>
	</description>
	<pubDate>Tue, 09 Aug 2011 16:35:10 +0900</pubDate>
	<dc:creator><![CDATA[지름신의 형제, 비즈토크]]></dc:creator>
</item>
<item>
	<title><![CDATA[힙 조각화와 LFH(Low Fragmentation Heap)]]></title>
	<link>http://byung.egloos.com/5347066</link>
	<guid>http://byung.egloos.com/5347066</guid>
	<description>
	<![CDATA[ 
애플리케이션에서의 메모리 이슈는 항상 쉽게 다뤄지지 않는 어려운 문제이다. 애플리케이션의 컴파일 이후 테스트 시에, 또는 초기 운영 시에는 좀처럼 나타나지 않지만, 사용자의 증가나 어느 정도 안정되게 운영된다고 생각하는 시점에 불현듯 나타나기 때문에 문제 재현도 쉽기 않고 해결 역시 쉽지 않다. 그 중에 힙 메모리의 조각화에 따른 문제는 상당히 골치 아픈 문제이다. 힙 메모리의 조각화는 일반적으로 메모리 할당과 해제에 코딩상 문제가 없음에도 불구하고 사용자의 패턴에 의해서 발생할 수 있는 현상이다. 일반적으로 메모리 관리자는 메모리의 해제 리스트를 관리하고 있다. 메모리를 할당하려고 할 때, 메모리 해제 리스트를 검색하여 재 할당 가능한 연속된 메모리 영역이 존재한다면, 해당 이미 해제된 메모리를 재사용하는	]]>
	</description>
	<pubDate>Tue, 29 Jun 2010 10:54:41 +0900</pubDate>
	<dc:creator><![CDATA[기억속으로 날다]]></dc:creator>
</item>
<item>
	<title><![CDATA[MS SQL Server 2005 인덱스 조각화 통계, 조각 모음]]></title>
	<link>http://todal94.egloos.com/2598725</link>
	<guid>http://todal94.egloos.com/2598725</guid>
	<description>
	<![CDATA[ 
지정한 테이블에 대한 정보 반환  다음 예에서는 AdventureWorks 데이터베이스에 있는 Person.Address 테이블의 모든 인덱스와 파티션에 대한 크기 및 조각화 통계를 반환합니다. 최대한의 성능을 발휘하고 반환되는 통계를 제한하기 위해 검색 모드를 'LIMITED'로 설정합니다. 이 쿼리를 실행하려면 최소한 Person.Address 테이블에 대한 CONTROL 권한이 필요합니다.    DECLARE @db_id SMALLINT;  DECLARE @object_id INT;    SET @db_id = DB_ID(N'AdventureWorks');  SET @object_id = OBJECT_ID(N'AdventureWorks.Person.Address');    IF @db_id IS NUL	]]>
	</description>
	<pubDate>Fri, 07 May 2010 10:50:13 +0900</pubDate>
	<dc:creator><![CDATA[Soon it shall also come to pass.]]></dc:creator>
</item>
<item>
	<title><![CDATA[.Net Framework에서 Memory Fragmentation과 Pooling]]></title>
	<link>http://whiteberry.egloos.com/1951873</link>
	<guid>http://whiteberry.egloos.com/1951873</guid>
	<description>
	<![CDATA[ 
1. 메모리 단편화 현상  Garbage Collector에 의해 대부분의 케이스에서 적절히 잘 처리되고 문제도 없지만, pin 되어버린 메모리가 많아지는 케이스에서는 아무리 GC님이 힘써도 단편화 현상은 어느정도 발생할 여지가 있는 듯. 뭐랄까, GC가 제어불능이 되는 영역이 많아져버리는 느낌 ?    2. 풀링  .Net Framework 상에서 풀링을 하는건 아무래도 삽질-_-이라는 느낌은 있다.  하지만, pin이 확정적-_-인 메모리는 풀링을 빙자한 짱박기-_-를 할 수밖에 없는 듯. pin할만한 녀석을 함유한 오브젝트를 과도하게 땡겨버리면, GC는 일 못하고, GC가 관리할건 많아지고 결과적으로 대참사가 벌어지더라... (...)    반면에, 그런 용도가 아닌 부분에 대해서 풀링을 하는 것은 역	]]>
	</description>
	<pubDate>Thu, 24 Sep 2009 10:35:10 +0900</pubDate>
	<dc:creator><![CDATA[sphere burster ; whiteberry edition]]></dc:creator>
</item>
<item>
	<title><![CDATA[IP Fragmentation]]></title>
	<link>http://xeraph.egloos.com/4827247</link>
	<guid>http://xeraph.egloos.com/4827247</guid>
	<description>
	<![CDATA[ 
TCP/IP Illustrated Vol 1. 내용 요약.    IP Fragmentation은 전송 중 데이터그램이 MTU보다 큰 경우 어디에서나 발생할 수 있다. 한 번 분할된 패킷이 다시 분할되는 것도 가능하다. (인덱스가 아니라 오프셋을 기록하니까) 그리고 전송 계층(TCP, UDP 등)은 IP Fragmentation에 대해서 모른다. 이것은 분할된 부분 중 하나라도 유실된다면 전체 데이터그램이 다시 전송되어야 함을 의미한다. IP 자체는 타임아웃이나 재전송이라는 개념이 없으니 상위 계층에서 전체를 다시 보내게 되는 것.    IP 헤더의 Identification 필드는 각 데이터그램의 식별 번호를 담고 있으며, Fragmentation 되는 경우에도 이 Id값은 그대로 복사된다. Fragment	]]>
	</description>
	<pubDate>Wed, 28 Jan 2009 00:40:12 +0900</pubDate>
	<dc:creator><![CDATA[Xeraph@NCHOVY]]></dc:creator>
</item>
<item>
	<title><![CDATA[.NET Library의 Async socket에서 메모리 누수 현상 (Buffer가 pinning ??)]]></title>
	<link>http://byung.egloos.com/4213176</link>
	<guid>http://byung.egloos.com/4213176</guid>
	<description>
	<![CDATA[ 
.Net LIBRARY에서 제공하는 Socket 통신 Application을 작성하여 수행 하다 보면, 예상치 못하게 메모리 누수가 발생하는 것을 경험할 때가 있다. 작성된 code가 흔히 볼 수 있는 code이므로, .NET Framework의 Bug가 아닌가 하는 의문마저 들게 하는 데, “KB947862: With dot net sockets and overlapped I/O you see a spike in memory in your application” 문서는 Asynchronous Socket operations, 특히, Socket.BeginReceive 등에서 사용하는 bytes buffer(또는 System.Threading.OverlappedData) 에서 heap fragmentatio	]]>
	</description>
	<pubDate>Mon, 10 Mar 2008 17:56:55 +0900</pubDate>
	<dc:creator><![CDATA[기억속으로 날다]]></dc:creator>
</item>
<item>
	<title><![CDATA[[경영] 슈와츠의 시나리오 예측법]]></title>
	<link>http://rapidme.egloos.com/3366716</link>
	<guid>http://rapidme.egloos.com/3366716</guid>
	<description>
	<![CDATA[ 
출처 :  세계적인 미래학자 피터 슈워츠가 제시하는 인류의 미래 시나리오 몇 편이라네요.  ■ 시나리오1. 가능성에 도전하는 기업  “불확실성으로 가득한 경영 환경에 효율적으로 대비 -&amp;gt; 현재 세계적인 금융 혼란(turmoil)의 한가운데 -&amp;gt; CEO들 -&amp;gt;  ‘과연 신규 인력을 채용해야 하나’ ‘우리가 연초에 세웠던 사업 계획들을 계속 밀고 나가야 하나’ ‘구조조정을 해야 하나’ ‘투자 포트폴리오를 수정해야 하나’ 등등…. 이외에도 가장 중요한 때는 바로 신규 사업을 시작할 때.”  “눈을 크게 뜨는 게 중요합니다. -&amp;gt; 과연 어떤 기업이 세계 최초로 휴대전화 기술을 개발했을까요? 바로 AT&amp;amp;T예요. 1980년에 기술을 개발했지만 오늘날 이 회사는 휴대전화를 팔지 않죠! -&amp;g	]]>
	</description>
	<pubDate>Sat, 01 Sep 2007 16:58:56 +0900</pubDate>
	<dc:creator><![CDATA[WE의 天劍]]></dc:creator>
</item>
	</channel>
</rss>

