이슈 및 버그 관리 툴리 필요하던 참에..

Jira 를 쓰고 싶었으나 유료임으로 패스하고.. 그나마 검증된 Mantis 를 사용하기로 결정.

윈도우용 Mantis 에 대한 자료가 그리 많지 않아..

설치하면서 이슈가 되었던 부분 몇 가지 정리합니다.

1. PHP for IIS 패키지 설치

   ==> 그냥 설치만 하면 다 되는 줄 알았는데.. IIS 의 풀에서 32비트 호환 모드로 설정해 주어야만 동작

  그 이후로는 일반적인 설정 작업하면 됨

2. Mail 설정 (GMail로 사용)

  Config_inc.php 화일에서 아래와 같이 설정

$g_phpMailer_method  = 2;

$g_smtp_host   = 'smtp.gmail.com';

$g_smtp_port   = 587;

$g_smtp_username  = 'g-mail ID';   /

$g_smtp_password  = 'g-mail PW';

$g_smtp_connection_mode = 'tls';

윈도우즈 폴더에서 php.ini 화일 열어서 아래의 주석 해제

;extension=php_openssl.dll  =>  extension=php_openssl.dll

별것 아니긴 하지만.. 사소한 부분이 엄청 시간을 소비하기에 포스팅 합니다.

2015.1 추가 내용

Mantis 를 이용시 외부 메일 서버를 통해 메일 발송하려 할 때 원인을 알수 없는이유로 메일이 발송되지 않는 경우가 발생,

Cron으로 메일 발송하게끔 수정 후 윈도우 잡스케쥴러에서 아래의 작업을 반복적으로 실행하게끔 설정하니 깔끔하게 해결됩니다.

php.exe -f scripts\send_emails.php

징가의 최근 이야기.

원문

http://media.daum.net/digital/game/newsview?newsid=20150526211305699

'화무십일홍'. '열흘 붉게 핀 꽃은 없다'라는 뜻이다. 아무리 흥한 것도 시간이 지나면 반드시 쇠한다는 교훈을 담고 있는 이 말은 인생의 덧없음을 말하기도 하지만, 많은 기업과 경영인들에게 '성공은 오래가지 못한다'는 큰 울림을 주는 격언이기도 하다.

이는 빠르게 변화하고 있는 IT 시장도 마찬가지다. 불과 10년 만에 스마트폰이 사람들의 필수품이 되어버렸고, 소셜네트워크서비스(이하 SNS)가 하나의 문화로 자리잡을 정도로 급변하는 시장을 선점하기 위해 수 많은 기업들이 시장에 뛰어들어 성공했고 또 실패하여 사라져갔다.

스마트폰 시장의 폭발적인 증가를 바탕으로 한 모바일 게임 역시 초창기 캐주얼게임의 장르에서 시작해 이제는 콘솔과 PC, 온라인게임 플랫폼에 이어 게임 시장의 중심으로 떠오르는 등 기존의 그 어떤 플랫폼 보다 빠르게 성장세를 이어가고 있는 상황이다.

이 같은 시대의 흐름 속에서 변화하는 게임 시장을 먼저 선점하여 대세로 떠올랐지만 불과 2년만에 곤두박질 친 회사가 있다. 바로 신생 게임 기업의 신화로 통하는 '징가'가 그 주인공이다.

한 때 창립 후 불과 5년만에 10억 달러(한화 약 1조 원)의 매출을 기록하며 새로운 게임 플랫폼 등장의 신호탄을 알렸다는 평가를 받았던 '징가'. 미국 나스닥에까지 상장하며 영원한 성장을 이어갈 것만 같았던 '징가'는 현재 연이은 인력감축으로 수 많은 게임 스튜디오가 폐쇄되고 회사의 존폐가 위험할 정도로 끝 모른 추락을 이어가고 있는 중이다. '게임 역사상 가장 엄청난 성장을 거둔 회사'로 불리던 '징가'는 왜 이런 위기에 처하게 된 것일까?

2007년 4월 창업자 '마크 핀커스'는 게임회사인 'Presidio Media'을 창업했고 3개월이 지난 7월 자신이 기르던 불독의 이름인 'Zynga'에서 이름을 따 회사의 이름을 '징가'로 변경하여 지금의 회사 기틀을 갖췄다.(회사의 로고 역시 이 불독의 이미지를 그대로 사용한 것) 당시 미국 IT 시장은 페이스북과 트위터의 대성공으로 인해 창업 열풍이 불고 있었고, '징가' 역시 이러한 분위기에 힘입어 미국의 여러 벤처 캐피탈(BC)회사에서 투자를 받아 설립된 수 많은 회사 중 하나였다.

비록 여러 신생 회사를 설립한 경험이 있었지만 게임회사를 처음 창립한 '마크 핀커스'는 트위터와 함께 엄청난 성공을 거두고 있던 소셜네트워크서비스 '페이스북'에 주목했다. SNS의 열풍으로 나나 할 것 없이 소셜 요소에만 집중하던 시기. '징가'의 창립 멤버들은 SNS을 통해 끝없이 전파되는 정보의 움직임에 주목했고, 이에 자신들의 게임을 페이스북에 서비스하기 위한 작업에 착수한다.

사실 징가의 게임들은 이미 웹으로 서비스되는 게임의 상당수를 그대로 도입해 만든 경우가 많았으며, 회사에서 선보인 최초의 게임인 '텍사스 홀덤 포커' 역시 이전에 있었던 카지노 게임과 별반 차이가 없었다.

하지만 징가는 이러한 게임에 여러 사람과 함께 할 수 있는 지금의 소셜 요소를 도입했고, 2007년 5월 페이스북이 자신들의 플랫폼에 적용할 수 있는 API(운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식- 두산백과)를 공개하자 이를 발 빠르게 적용하여 페이스북에 입점하기에 이른다.

SNS를 통해 기존의 메신저 서비스 이상의 콘텐츠를 찾던 페이스북 역시 게임이라는 콘텐츠를 SNS에 접목시킨 '징가'의 입점을 환영했고, 이 두 회사는 소위 말하는 '악어와 악어새'와 유사한 공생 관계를 맺게 된다.

농작물 키우기 혹은 라이트한 카지노 게임과 같은 간편한 게임 시스템, 그리고 혼자서 하는 게임이 아닌 SNS 친구들과 함께하는 '소셜 요소'까지 '징가'는 일반적인 웹기반의 게임에 SNS를 더하면서 게임에 관심이 없던 일반인들까지 자신들의 게임에 집중하게 만드는데 성공했다.

사람들이 원하는 것이 무엇인지 정확하게 꿰뚫어 본 '징가'는 페이스북에 입점한 지 불과 1년만인 2008년 월 사용자 90만명이라는 엄청난 기록을 세우며 자신들의 선택이 옳았음을 증명했다. 더욱이 2009년 전세계에 소셜네트워크게임(SNG)이라는 하나의 장르를 만들어낸 게임 '팜 빌리지'를 출시하며 이 같은 성공은 더욱 가속화된다. 2009년 하반기 일 사용자 2천 만 명, 월 사용자 2억 명이라는 유례없는 기록을 세운 '징가'는 이러한 성장을 바탕으로 지속적인 투자를 유치하고 성장해 나가며 그야말로 SNG의 전성기를 활짝 열어 놓았다.

이러한 '징가'의 성공을 본 많은 게임사들은 앞다투어 SNG을 선보이며 점차 시장이 활성화 됐고, 거대 게임 회사들을 소셜 게임에 뛰어들게 만드는데 일조 했으며, EA는 플레이 피쉬, 팝캡 게임즈 등을 인수하고, 마이크로소프트도 소셜 게임 개발사 '크라우드스타'를 인수했다. 특히, 징가와 경쟁 관계에 있던 플레이 피쉬를 인수한 EA는 단숨에 징가에 이어 페이스북 게임 2위로 올라서는 기염을 토하기도 했다.

이에 시장을 선점한 '징가' 역시 일본과 중국의 개발사들을 인수하는 방식으로 후발주자들을 따돌리며 계속 앞으로 나아갔다.

2010년 페이스북이 페이스북 플랫폼에서 서비스되는 게임들의 유료 콘텐츠를 자신들의 수익으로 돌리기 위해 도입한 '페이스북 크레딧'으로 대체한다는 방침을 발표하자 이에 '징가'가 반발하며 둘의 사이는 틀어지는 듯 했다.

하지만 게임과 광고를 포함해 매출의 12%를 담당할 정도로 비중이 커져버린 '징가'를 페이스북은 완전히 외면하지 못했고, '장가' 역시 새로운 플랫폼을 찾지 못한 상황에서 페이스북과 관계를 청산하는 것에는 위험부담이 너무 높았다. 때문에 '징가'는 2015년까지 '페이스북 크레딧'을 사용하는데 합의했고, 페이스북 역시 지속적인 서비스 제공을 약속하며 둘의 관계는 다시 원만해졌다.

쉽고 간편한 소셜 게임으로 성공을 거뒀지만, 동종 장르의 게임들과 표절 논란을 끊임없이 겪던 '징가'. 이러한 논란을 해결하기 위해 '징가'의 수뇌부는 막강한 자본력을 바탕으로 논란을 겪던 다수의 모바일게임사를 인수해버리는 엄청난 방식을 채택한다. 이 과정 속에서 수 많은 게임 스튜디오가 생기게 된 징가는 2010년 말 출시한 '시티빌'이 다시 대성공을 거두면서 월 사용자 1억명이라는 기록을 세우게 되며, 더욱 큰 규모의 게임사로 발돋움 하게 된다.

조그만 스타트업에서 시작한 회사가 불과 4년만에 2천 여명이 넘는 직원과 각 국에 게임 스튜디오를 거느리며 세계 유수의 게임기업들과 어깨를 나란히 하게 된 셈이다.

2011년 연 매출 11억 달러를 넘는 거대 회사로 성장한 '징가'는 많은 게임사들도 시도하지 못한 주식 상장을 '골드만삭스'와 '모건스탠리'를 통해 시도하며 주당 12달러라는 기록을 세우게 된다. 바야흐로 '징가'가 세계 게임사들 사이에 우뚝 선 순간이었다.

하지만 징가의 몰락은 가장 영광스러운 순간부터 시작됐다. 해를 지난 2012년 페이스북의 소셜 게임이 급격히 증가하자 소셜 게임들의 스팸성 광고가 사회적인 문제로 대두되기 시작했고, 이에 페이스북은 소셜 게임에 대한 안티 스팸 정책을 실시하기에 이른다. 이에 신규 가입자를 유치해 수익을 올리던 상당수의 소셜 게임사들이 무너지기 시작했고, 이는 점차 시장의 축소로 이어져 징가 역시 매출 감소에 시달린다.

또한, 이미 시대는 소셜 게임을 넘어 모바일 게임으로 전환되기 시작했지만 징가는 이에 적절히 대처하지 못했다. 흐름을 읽어 성공한 회사가 급격히 바뀌어 버린 환경에 적응하지 못한 셈이다.

이 같은 '징가'의 모습에는 경직된 회사 분위기와 기업 윤리의 실종을 기반으로 하고 있었다. 너무나 급격히 성장한 '징가'는 과도한 성과급 위주의 경영과 내부 경쟁을 우선시 하는 분위기 탓에 과중한 업무가 가중되는 분위기였고, 이에 직원들은 엄청난 스트레스에 시달리고 있었으며, 내부불만이 극에 달해 있었다. 더욱이 기업매출과 내부의 생산을 데이터화하여 평가하는 '징가'의 정책은 경직된 사고와 성과만이 우선시 되는 대기업 형태로 흘러갔고 내부 분위기는 급격히 경직됐다. 기업문화의 영향력을 완전히 무시한 결과가 서서히 드러나고 있던 것이다.

또한, 빠르게 성장하는 회사의 방향성을 잡아주어야 할 임원진들 역시 스스로의 성공에 취해 나태해 지고 있는 것도 문제였다. 너무나 빠르게 성장을 거듭하면서 관리직 임원들을 급하게 채용한 '징가'는 서서히 회사의 신념이나 원칙보다는 돈과 매출에만 이들이 늘어나면서 분위기가 퇴색되기 시작했다.

더욱이 일정 수익을 거두면 제공되는 인센티브 정책을 없애버리며 직원들의 사기를 꺾은 것에 이어 주식 상장 이후 자신의 주가 전부를 팔아버린 '마크 핀커스' CEO의 행동은 징가의 기업 가치를 떨어뜨리는데 큰 영향을 미쳤다.

내부 경쟁이나 일삼으며 매출 위주로 흘러가는 경직된 분위기, 덩치는 커졌지만 이미 생산력을 잃어버린 개발진들, 그리고 경영진들의 과도한 탐욕까지 '징가'는 빠른 성공 이후 그 어떤 게임회사보다도 빠르게 경직되며 성장 동력을 잃어버렸다.

사실 '징가'는 모바일 게임의 대두에 따른 대처를 완전히 포기한 것은 아니었다. '징가'는 2011년 이미 '앵그리버드'로 유명한 '로비오'를 비롯한 여러 모바일게임사들을 인수하기 위한 작업에 착수했다. 하지만, 이들 회사들 상당수는 '징가'의 경직되고 비효율적인 내부 분위기를 우려하며 이 제안을 거절하고 만다.(이중 '로비오'에 제안한 인수 금액은 무려 '22억 달러' 한화 약 2조에 달한다. 하지만 이러한 제안도 거절할 만큼 '징가'의 내부 경쟁과 업무 스트레스는 유명했다)

계속되는 실적 악화와 경직된 회사 분위기. 내부 경쟁 탓에 수 많은 게임 스튜디오의 인재들을 제대로 활용하지 못하던 '징가'는 덩치는 불렸지만 속은 병들어가는 소위 '대기업병'에 걸린 회사들과 같은 길을 걸어가기 시작한다. 실적 악화를 이유로 대규모 구조조정을 감행한 것에 이어 전세계에 흩어져 있던 게임 스튜디오를 정리하기 시작했다.

하지만 이런 노력에도 불구하고 징가의 주식은 반토막을 넘어 곤두박질 쳤고, 14달러에 이르던 징가의 주식은 2달러 선에 머물고 있는 상황이다. 현재 징가는 한 번의 큰 구조조정을 거친 이후 다시 제기를 위해 모바일게임 산업에 뛰어들고 있지만 지금까지 이렇다 할 성과를 거두지 못하고 있는 중이다. 한 때 전세계 게임사들과 어깨를 나란히 했던 회사 치고는 너무도 초라한 모습이라고 할 수 있다.

'징가'의 성공 요인에는 시대의 흐름을 읽은 과감한 시도와 새롭게 대두되던 플랫폼을 통해 시장을 먼저 선점했으며, 다양한 게임을 통해 게이머들의 입맛을 충족시켜 주었다는 것에 있었다. 이러한 징가의 시도는 엄청난 성공으로 이어져 유례없이 기록적인 성장을 거둔 징가의 신화에 큰 영향을 미쳤다.

하지만 변화하는 시대에 대처하지 못해 뒤쳐진 회사의 정책과 급격한 성장에 따라 빠르게 진행된 대기업화를 통한 경직된 내부 분위기. 그리고 기업윤리가 실종된 경영진의 태만까지 기업의 성장통을 이겨내지 못하며 성공을 이어가지 못하고 주저앉고 말았다. 시대의 흐름을 타 성공한 기업이 계속 흐름을 타지 못하면 어떻게 되는지 똑똑히 보여준 사례라고 할 수 있다.

이러한 '징가'의 실패는 국내 게임사들에게도 좋은 반면교사가 될 수 있다. 더욱이 세계 스마트폰 시장 3위를 기록할 정도로 많은 매출이 발생하는 국내 모바일게임 시장의 성장과 함께 커온 모바일게임사들 역시 '징가'의 실패와 같은 모습을 겪지 않으리라는 보장은 없다.

한 때 세계 최고의 게임사를 꿈꿨지만 3일 천하가 되어버린 '징가'의 추락. 과연 징가는 다시 예전의 위상을 되찾을 수 있을까?

급변하는 게임시장의 흐름 속에 성공을 거둔 국내 게임사들 역시 이러한 전철을 밟지 않기를 바라며 글을 마친다.

글 / 게임동아 조영준 기자 <june@gamedonga.co.kr>

사용자 중심의 게임 저널 - 게임동아(game.donga.com)

SQL Server 가 설치된 서버의 CPU 사용율이 급등하고 있다면..

대부분의 경우에는 디스크 IO를 많이 유발시키거나 아니면 인덱스를 잘 못 타고 있어서 발생하고 있는 경우가 대 부분입니다.

그런데 이러한 경우 프로필러로 보면 어떤 쿼리에서 문제가 되는지 일부는 쉽게 확인 할 수 있지만..

CPU의 과도한 사용 때문에 응답이 늦는 경우에는 발견하기 어려운 경우도 종종 발생합니다.

이럴 때 확인 할 수 있는 쿼리는 아래 와 같습니다.

1. 실행 가능 작업의 값 확인 하기

SELECT
Scheduler_ID,
Current_Tasks_Count,
Runnable_Tasks_Count
FROM
SYS.DM_OS_SCHEDULERS
WHERE
Scheduler_ID < 255

2. CPU를 많이 사용하는 상위 50개의 SQL 문 확인하기

SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
Total_Physical_Reads,
SUBSTRING(b.text,a.statement_start_offset/2,
(case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
else
a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
dbname=Upper(db_name(b.dbid)),
b.objectid AS 'Object_ID'
FROM sys.dm_exec_query_stats a
CROSS APPLY
sys.dm_exec_sql_text(a.sql_handle) AS b
ORDER BY
[Avg_CPU_Time] DESC

요즘 DB 에 대해 조금 깊이 있게 공부를 하고 있는데..

알면 알 수록 재미 있는 부분들이 많이 있네요. ^^

 본 글은 Brad McGehee 님이 기고한 글을 번역한 문서입니다.

작성된지는 조금 오래(2005년) 되었지만 DB 서버의 성능을 측정하는 지표로 활용하는데에는 전혀 부족함이 없어 보입니다.

물론 SQL Server 버젼별로 성능 카운터가 더 많이 추가 되어서 버젼별로 상세한 상태를 확인 하는 부분에 대해서는 MSDN 의 On-Line 문서를 확인 하시는 것도 좋을 것 같습니다.

 번역 내용에 오역이 있더라도 널리 양해를 구합니다. (본문도 첨부합니다. )

Tips for Using SQL Server Performance Monitor Counters

SQL Server Access Methods object: Page Splits/sec

SQL Server 에서 I/O 를 초과하는 이유 중 하나는 page splitting이다. Page splitting 은 index나 data page가 꽉 찾을 때 현재 page와 새로 할당 된 page 사이에서 발생한다.  일반적으로 page splitting 이 일어 나는 동안 디스크 I/O를 초과할 수 있고 성능을 저하 시키게 된다.

만약 서버상에서 많은 수의 page splits 를 발생하는 것을 확인하길 원한다면 SQL Server Access Methods object: Page Splits/sec 으로 모니터링 할 수 있습니다. 만약 page splits 가 높다면 index 들의 fill factor 를 증가시키는 것을 고려 할 수 있습니다. Fill factor 의 증가는 데이터를 채우기 전의 방(pages)을 더 많이 만든 다음 page split 이 발생되기 때문에 성능의 향상을 가져올 수 있습니다.

높은 수치의 Page Splits / sec 은 무엇을 의미하는가 ? 거기에 대한 간단한 답은 없습니다. 그것은 시스템상의 I/O subsystem상의 무엇인가로부터 영향을 받는 다는 것입니다. 하지만 일반적인 기본 조건에서 디스크 I/O 성능의 문제를 발견한다면 이 카운터는 보통 100 이상의 수치를 나타낼 것이고 그 때 Fill factor 의 증가가 성능의 향상을 가져올 수 있습니다.

*****

QL Server Buffer Manager Object: Cache Size (pages)

만약 서버상에 얼마나 많은 물리적인 RAM 이 SQL 서버의 data cache 에 할당되었는지 보고 싶다면 SQL Server Buffer Manager Object: Cache Size (pages) 으로 확인 할 수 있습니다. 이 수치는 page들 안에서 표현됩니다. 그렇기 때문에 8K(8,192) 단의로 확인할 수 있으며 이것으로 RAM의 몇 K가 할당되어져 있는지 확인 할 수 있습니다.

일반적으로 이 수치는 서버 전체 RAM 의 사이즈와 유사한 것이 좋고 NT, SQL Server나 기타 다른 유틸리티들의 ram 보다 작습니다.

만약 특정 양의 RAM을 데이터 캐시에 할당하였다면 당신이 예상하는 것보다 그 사이즈는 작을 것입니다. 이럴 때 당신을 그 원인을 찾기 위해 확인을 해 볼 필요가 있습니다. 아마도 당신은 SQL Server가 동적 RAM을 할당하거나 SQL Server가 순간적으로 성능 최적화을 위해 적은 양의 RAM으로 이 사용되는 것을 원하지 않을 것입니다. 어떤 이유에서건 이것에 대한 해결책이 필요하고 데이터 캐시의 양이 SQL Server는 SQL Server의 성능에 영향을 미친다는 사인이 될 수 있습니다.

실제로는 다른 항목으로 SQL Server의 메모리가 부족하지 않는지 확인 하는 더 좋은 방법이 있기 때문에 이 카운터를 보기 위해 많은 시간을 허비하지는 않습니다.

*****

SQLServer: SQL Statistics: Batch Requests/Sec 

SQL Server가 얼마나 바쁜지 피부로 느끼기 위해 확인하는 카운터는 SQLServer: SQL Statistics: Batch Requests/Sec  입니다. 이 카운터는 SQL Server 초당 수신한 batch request들의 수를 나타내고 일반적으로 서버의 CPU가 얼마나 busy 한지를 측정하는 용도로 이용합니다. 일반적으로 말하지만 초당 1000 batch request 가 넘는다면 이것은 매우 busy 한 상태의 SQL Server를 나타내고 있고 만약 CPU 병목현상을 이미 경험하지 못하였다면 곧 그러한 상황이 닦칠 수 있다는 의미이기도 합니다. 물론 이것은 상대적은 수치이고 더 좋은 하드웨어를 갖고 있다면 더 많은 수의 batch request 를 처리 할 수 있습니다.

네트웍 병목 현상으로는 일반적으로 100 Mbps 네트웍 카드는 일반적으로 초당 3000 batch request 만 가능합니다. 만약 이 서버가 이 정도로 busy 상태를 유지한다면 네트웍 카드를 하나 더 추가하거나 1 Gbps의 네트웍 카드로 변경하는 것이 필요합니다.

일부 DBA 들을 SQLServer: Databases: Transaction/Sec: _Total  를 SQL Servver 의 전체 활동량을 측정하기 위해 이용합니다.  하지만 이것은 그리 좋은 생각이 아닙니다. Transaction/Sec  은 모든 activity 를 측정하지 않고 Transaction 안에 있는 activity 만을 측정하게 됩니다. 그렇기 때문에 Transaction/Sec  대신에 항상 SQLServer: SQL Statistics: Batch Requests/Sec 카운터를 이용하여 측정하는 것이 좋습니다.

*****

SQLServer: SQL Statistics: SQL Compilations/Sec

Transact-SQL 코드의 SQL 컴파일이 발생하는 것은 SQL Server가 수행하는 정상적인 영역의 일부입니다. 하지만 컴파일은 CPU 와 기타 리소스를 많이 사용하기 때문에 SQL 은 가능하면 캐시 안의 수행 계획 (execution plan)안에서 재수행 할 수 있도록 작성하는 것이 좋습니다. (execution plan은 컴파일이 발생할 때 생성됩니다.)  더 많은 실행 계획들이 이용됐다는 것은 서버상의 더 적은 오버헤드를 유발시키고 성능을 더욱 향상시키게 됩니다.

서버상에서 얼마나 많은 compilation이 발생했는지 확인하기 위해서는 SQLServer: SQL Statistics: SQL Compilations/Sec 카운터를 이용할 수 있는습니다.  예상할 수 있듯이 이 카운터를 초당 얼마나 많은 컴파일이 발생했는지는 나타냅니다.

일반적으로 초당 100 compilation 이상 발생한다면 서버상에 불필요한 오버헤드를 발생하고 있다는 것입니다. 수치가 높다는 것은 서버가 의미없이 바쁘거나 수행중에 불필요한 재컴파일이 발생한다는 것입니다. 예를 들어 object의 스키마가 변경되었거나 병렬 실행 계획이 질렬로 수행된다거나, 통계가 재계산되었거나 다른 일들이 발생하였다면 SQL Server는 강제적으로 재컴파일 할 수 있습니다. 어떤 경우에는 불필요한 컴파일을 숫자를 줄일 수 있습니다. 이 곳에서 page 좀 더 자세한 내용을 확인 할 수 있습니다.

*****

SQLServer: Databases: Log Flushes/sec counter 

SQLServer: Databases: Log Flushes/sec counter  은 초당 로그가 디스크에 쓰여지는 (flush) 되는 수치를 나타냅니다. 이것은 데이터베이스 레벨별로 또는 전체에 대해서 측정할 수 있습니다.

정확히 log flush 란 무엇일까요 ? 이것을 설명하는 가장 좋은 방법은 예를 드는 방법입니다. 예를 들어 당신이 10 개의 INSERT 문을 수행하는 트랜잭션을 시작한다고 가정해 본다면 첫 번째로 INSERT 가 실행되고 새로운 데이터가 데이터 페이지로 삽입됩니다. 이것은 동시에 2가지가 발생됩니다. 이 때 버퍼 캐시 안에 있는 데이터 페이지는 새로운 INSERT Row 데이터로 갱신되는 것과 그리고 로그 파일을 위해 데이터를 책정합니다. 이 것은 트랜잭션이 완료될 때까지 계속됩니다. 동시에 로그 캐시로부터의 이 트랜잭션을 위한 데이터는 즉시 log file 에 기록합니다. 하지만 버퍼 캐시에 머물고 있는 데이터는 다음 번 checkpoint 프로세스가 실행되기 전까지 남아 있게 되고 checkpoint 가 실행될 때 데이터 베이스는 새로운 INSERT row들이 갱신합니다.

그 동안 log cache 라는 부분에 대해서 전혀 들어보지 못 했을 수도 있지만 log cache는 SQL Server 가 데이터를 log file 에 쓰기 위해 기록하는 메모리 위치입니다. Log cache 의 목적은 한 트랜잭션을 commit 하기 전에 roll back 하는데 이용하기 위해 사용 하는 것으로 매우 중요합니다.  하지만 단지 한 트랜잭션이 완료되면 (더 이상 롤백은 할 수 없음) log cache 는 물리적 로그 파일로 즉시 방출(flush) 하게 됩니다. 이것은 일반적인 처리입니다. SELECT 쿼리들은 데이터를 수정할 수 도 없고 트랜잭션을 생성할 수 없고 log 방출 역시 하지 않는 다는 것을 기억하십시요.

본질적으로 로그 방출(Log Flush)은 log cache 로부터 물리적인 log file 로 기록될 때 발생합니다.  그래서 기본 성질은 log flush 는 트랜잭션이 완료될 때마다 발생되게 되고 여러 개의 트랜젼션의 수와 관련되어 SQL Server에 의해서 발생되게 됩니다. 그리고 예상하듯이 log flush 의 사이즈 (얼마나 많은 데이터를 물리적 디스크로 기록할 것인가에 대해) 는 트랜잭션에 따라 매우 다양해 집니다. 이 정보는 어떤 의미를 우리에게 전달할까요 ?

이미 우리는 disk I/O 의 병목에 대해서 경험하고 있다고 가정해 봅니다. 하지만 우리는 그에 대한 원인을 전혀 모르고 있는 상태이구요. 디스크 I/O 병목에 대해서 문제 해결을 할 수 있는 한 가지 방법은  초당 기록되는 log flushed 카운터(Log Flushes/sec counter)를 캡쳐 하고 얼마나 busy 상태인지 확인 하는 것입니다. 이미 예상할 수 있듯이 만약 서버가 많은 수의 트랜잭션을 처리하고 있다면 그것은 또한 많은 수의 log flush 가 발생하고 있다는 의미이고 그 수치는 트랜잭션을 생성하는 action-type 쿼리들이 얼마나 busy 상태인지를 나타내는 서버들간의 수치로 확인 됩니다. 당신이 이 정보로 하고자 하는 것은 당신의 서버에서 예상했던 것보다 더 많은 수치의 log flush 가 발생한다는 상황입니다.

예를 들어 한 테이블에 매일 백만건의 INSERT 가 발생하고 거기에는 insert 하는 여러 가지 다른 방법이 있습니다.  첫 번째로 각각의 row가 개별적으로 insert 될 수 있고 각 INSERT 문장은 sinlgle transaction 으로 wrapped 되어 있습니다. 두 번째는 모든 INSERT 문장은 하나의 transaction 문장 안에 포함되어 있습니다. 그리고 마지막으론 INSERT 문장이 다중 트랜잭션(multiple transaction) 문장안에 나뉘어져 들어가 있고 어디선가 1에서 1,000,000 까지의 INSERT 하게 됩니다. 이 세 가지의 경우는 옵션이 다르고 SQL Server 상에서 작용하는 효과 역시 다르게 나타나고 초당 log flush 의 수 역시 다르게 나타납니다. 덧붙이자면 이것은 그렇게 생각하던 아니던 당신의 프로세스에서 하나의 트랜잭션만 발생한다고 착각하기 쉬운 경우입니다. 대부분의 사람들은 하나의 프로세스는 하나의 트랜잭션만 유발한다고 생각하는 경향이 있습니다.

자.. 첫 번째 경우 백만건의 row 를 백만번 트랜잭션으로 INSERT 하게 되면 거기에는 또한 백만번의 log flush 가 발생합니다. 하지만 두 번째의 경우에는 백만건의 row 가 단 하나의 트랜잭션안에서 INSERT 하게 될 것입니다. 그리고 이 경우에 log flush 는 한 번만 발생하게 됩니다. 그리고 세 번째의 경우에는 log flush 의 수치는 트랜잭션의 수와 동일하게 됩니다.  사실 log flush 의 크기는 한 트랜젹션으로 처리하는 것보다는 백만 건의 트랜젼션으로 처리하는 것 보다 커질 것이다. 하지만 대부분의 경우에 이것은 여기에서 설명하듯이 성능을 측정하는 것에는 중요하지 않다.

자.. 어느 옵션이 가장 좋을까 ? 모든 경우에서 당신은 여전히 많은 disk I/O 를 유발시킬 것입니다. 백만건의 row를 처리 할 것이라면 이 상황을 개선시키는 확실한 방법은 없을 것이다. 하지만 하나 또는 몇 개의 트랜잭션으로만 처리한다면 log flush 의 수치를 줄일 수 있고 이로 인해 disk I/O 를 상당 부분 줄임으로 인해 I/O 병목에 대해 개선할 수 있을 것입니다.

 이것으로 우리는 이것을 통해 2가지를 확인 할 수 있었습니다.. 첫 번째는 최대한 log flush 를 줄이기를 원한다는 것이고 이는 결국 당신의 서버상에서 트랜잭션의 수를 줄이는 것이 성능 개선의 방법이라는 것이다.

*****

SQL Server General Statistics Object: User Connections

SQL Server를 여러 명의 사용자들이 이용하기 시작한 이후부터 성능을 확인 하기 위해 SQL Server General Statistics Object: User Connections 수치를 눈여겨 볼 것이다. 이 것은 현재 SQL Server에 연결된 사용자의 수를 나타낸다. ( 전체 유저들의 수를 의미하는 것이 아니다. )

이 수치를 관찰할 때 한 유저가 여러 개의 연결(connection) 을 유지할 수 있고 여러 명의 사람들이 한 사용자의 connection 을 공유할 수 있다는 것을 주의해라. 이 수치가 실제 유저의 수치를 나타낸다고 착각하자 말아라 !! 대신 연관되어 측정할 수 있는 얼마나 “busy” 인가를 확인해라.  이 수치는 과거에 비해 서버가 얼마나 더 많이 이용되고 있는지 또는 얼마나 더 적게 이용되고 있는지만을 느끼는 정도로 이용해라.

만약 당신의 데이터베이스가 데드락(deadlocks) 으로 어려움이 있다면 SQL Server Locks Object: Number of Deadlocks/sec 값으로 측정할 수 있다. 하지만 이 수치가 상대적으로 높지 않다면 측정은 초 단위로 진행되고 인지할 수 있는 단지 몇 개의 데드락만을 측정 할 수 있기 때문에 더 많은 정보를 보기를 원할 것이다.

하지만 여전히 이 것은 데드락 문제를 갖고 있는지 확인 하는 데 유용하다. 더 구체적으로 확인하기 위해서는 SQL 프로필러의 데드락 추적 능력을 이용해라. 프로필러는 더 많은 상세한 정보를 제공할 것이다. Deadlocks/sec counter 의 수치를 확인해서 일반적인 큰 그림을 그리는데 사용하고 그 정보를 기초로 어떤 부분에 문제가 있는지 확인하기 위해서는 프로필러의 좀 더 상세한 분석을 통해 문제점의 “drill” down 할 수 있도록 이용해라.

vi 명령어 요약