Intelligence Hacker http://ydhoney.egloos.com Intelligence Hacker ko Thu, 19 Nov 2009 03:35:36 GMT Egloos Intelligence Hacker http://pds13.egloos.com/logo/200908/01/04/f0083504.jpg http://ydhoney.egloos.com 80 80 Intelligence Hacker <![CDATA[ 오라클/MySQL 대신 PostgreSQL이 대세가 될 날도 머지 않았다는 느낌이 든다 ]]> http://ydhoney.egloos.com/1972985 http://ydhoney.egloos.com/1972985
몇가지 이슈가 있다.

하나는 PG가 갈수록 심각하게 빠른 속도로 발전하는데다가 Enterprise DB가 나오면서 가장 크게 내세우는 장점이 Oracle Compatibility 라는 점이다. 뭐 쿼리 자체(어차피 특별히 뭔 짓을 하지 않는 표준 SQL이라면 뭐..)나 관리용 테이블, odbc/jdbc 컨트롤 등이 호환되는건 힘들겠지만 전반적인 User Level Table이라면 거의 그대로 포팅 가능한 수준이 된 것이 아닌가 하는 것이고..(이전에는 6~24Hour Migration 이라면 지금은 1Hour Migration 체제라고 이해하면 될 듯)

일단 상용 환경에서의 PG가 가지는 최고의 단점은 Commercial이 아니라는 것. 그 간격은 일단 EnterpriseDB나 PostgreSQL Plus 등이 어느 정도는 매꿔줘야 할 것 같고, 영업/유통은 레드햇이 같이 끼고 들어간다면 그리 힘들지만도 않을 듯 하다.

일단 엔지니어 커버는 아직 Oracle이나 MySQL 대비 국내 인력이 월등히 부족한 건 사실이지만 그렇다고 무슨 대단히 복잡한 짓을 하지 않는 이상 DBA 레벨이라면 기존 DB 하는 양반들도 다 할 수 있을것이라고 보고, 거기에서 뭔가 좀 더 심오한 부분으로 간다 하더라도 뭐 다른 DB라고 DBA가 튜닝한다는게 무슨 큰 의미가 있는 튜닝을 하는 시스템 전체를 바라보는, 혹은 DB만이라도 제대로 볼 줄 아는 실력이 있는 DBA가 많지 않으니까 어느 분야나 마찬가지라고 보는거고..결국 기술지원체계가 문제가 되는거겠지..

헌데 문제는 이런게 아니라, 얼마전에 Postgre측에서 CUDA 플랫폼 기반으로의 포팅을 시작했다는것이다. CPU 기반과 GPU 기반의 차이..일반인들은 잘 체감하기 어려울지도 모르지만 일반 우리가 쓰는 조금 비싼 그래픽카드만 해도 퍼포먼스가 한참 달라지고 여기에 Tesla MultiCore GPU 기반으로 간다면 I/O만 감당해 준다면 퍼포먼스가 정말 기하급수적으로 올라간다고 보면 된다. 뭐 개인적으로 기대하는 것은 Cell/BE 기반이지만 가격도 그렇고 아키텍쳐 플랫폼도 그렇고, 개발을 할래도 개발 플랫폼 제공이 되어야하는데 그게 힘들테니 감당할 것이 너무 커져서인가 하여간 DB계열에서는 그다지 관심을 받지 못하고 있는 듯 하다. (아니 그냥 PPC CPU 쓰는 하드웨어에 DK만 올리고 개발하면 되지 않느냐..라고 생각할 수준은 아닌것 같아서..)

뭐 MySQL도 CUDA로 가면 되지 않느냐고 하지만, 아니 근데 이미 MultiCore 기반이나 고성능 CPU에서 MySQL 대비 PG의 퍼포먼스가 확연히 차이나는 수준으로 PG가 앞서고 있는 마당에 고성능 CPU에서의 MySQL의 성장가능성을 논할 필요가 있을까 싶기도 하고, 아직 MySQL 계에서는 아직 논의의 수준을 벗어나지 못하고 있는것도 있고..그쪽에서도 크게 관심은 없는것 같더라고..(그리고 이미 MySQL은 오라클의 것이잖아? 오픈소스라고는 하지만 이미 로드맵이 서로 달라지는거지. 커머셜 레벨 기준으로 생각하고 갈텐데 실험적인걸 자꾸 도입하는걸 코어쪽에서 반기기는 힘들거고..누가 아예 백포팅해서 가지쳐 나가지 않는 이상..)

하여간 이래저래 갈수록 MySQL은 진화가 정체되는 느낌이고 PG는 갈수록 기하급수적으로 성장하는 느낌. 오라클은 뭐 어차피 상용레벨로 가야하니까..오라클은 Processing은 그냥 일반 CPU벤더쪽에 일임하고 별다른 움직임을 취하지 않는 상태로 MemoryDB질이랑 I/O 성능 개선하고 SSD홍보나 하고 관리툴이나 계속 복잡다양하게 만들어서 사용자 낚시질을 하고 있고..(그래도 11g는 참 좋은 제품인것은 틀림없어..)

근데 어차피 내년 후반 넘어가면 인텔이나 AMD나 CPU에 embeded GPU 방식으로 나올텐데 오라클 입장에서도 GPU processing에 대한 부분은 준비를 하지 않으면 한순간에 따라잡힐수도 있는 문제임에도 별다른 대응이 없는것은 다소 의아할 따름. 로드맵이 너무 확고해서 새로 가지쳐 뻗어나가기엔 버거운 것일까? 아니면 어차피 일반 사용자 레벨이나 기업 입장에서 GPU based DB 가 그렇게 혹하는 조건이 아닐 수도 있다고 생각하고 있거나, 혹은 Sun 인수하고 나서 좋은 유닉스 기반 CPU 생겼다고 히히덕거리고 있는건가?

아직도 현금 흐름 괜찮으면 차라리 Nvidia나 AMD(with ATI)나 인수하지 싶다. 그럼 오라클 입장에서는 정말 천군만마를 얻은 것 같을텐데..그게 좀 어려우려나? Sun 사는것보다 이 쪽이 더 이득이었을수도 있겠지 않겠어? 시너지 효과도 크고..MySQL때문에 이러지도 저러지도 못하고 겉으로 내색하진 않지만 좀 끙끙대고 있는 모습을 보자면 썬 사서 서버 시장까지 장악하는것보다 AMD나 Nvidia를 사서 CPU/GPU 라인업을 갖추고 GPU Based DB로 새로운 퍼포먼스의 세계로 들어가는게 장기적인 플랜에 더 맞지 않았을까?

하여간 DBA라면 PostgreSQL은 조금씩이라도 공부해 두는게 좋겠다. 어차피 지금도 오라클하고 경합할 거 MSSQL은 어차피 논외로 치더라도 IBM DB2 제외하면 PG밖에 없잖아?

p.s

근데 요즘 IBM이 AMD랑 굉장히 친하게 지내는데..여차하면 DB2가 오라클보다 GPU 기반 DB가 먼저 나올지도 몰라;; IBM에서 나온다면 only CUDA보다는 OpenCL일 확률이 높지만..^^

tag : , , , , , , ,  ]]> Linux/IT/Geek Oracle MySQL PostgreSQL DB2 cpu gpu cuda opencl http://ydhoney.egloos.com/1972985#comments Thu, 19 Nov 2009 03:33:53 GMT ydhoney <![CDATA[ DB서버 실데이터 FS에서의 noatime 사용 ]]> http://ydhoney.egloos.com/1957958 http://ydhoney.egloos.com/1957958
DB서버의 경우 I/O 퍼포먼스가 거의 대부분의 이슈를 차지합니다. 덕분에 실제로는 필요하지도 않지만 어쩔 수 없이 대용량의 스토리지를 구성할 수 밖에 없는 경우도 존재하지요. 물론 저용량/고속 퍼포먼스가 이슈라면 비슷한 가격에 SSD가 대안이 될 수도 있습니다..만 SSD의 퍼포먼스 향상에 대해서 진정 신뢰할 수 있는것일까요? 그건 잘 모르겠어요. 그렇지요? :-) SSD 자체의 실데이터 안정성에 대해서도, 적어도 DB서비스를 하기 위한 SSD를 얼마나 신뢰할 수 있을것인가 역시 고려할 문제지요. SSD Raid 스토리지를 2개 이상 구성하고 멀티 전원에 UPS도 열심히 박고 등등등의 온갖짓을 하지 않는 이상 SSD의 전기적 특성에 대한 무한한 신뢰를 보내기가 아직은 쉽지 않은것이 현실입니다. 그냥 편하게 디스크 Raid 5로 잔뜩 박아버리는게 답이란 말이죠.

DB 서버를 구성하고 웹서비스를 구축하다보면 별 개떡같은 경우를 다 보게 됩니다. 물론 운좋게 좋은 개발자를 만나서 질 높은 쿼리로 구성된 웹페이지를 서비스한다면 참 행복한 일이겠습니다만, 살다보면 외주도 주고 뭣도 하고 등등등 하다보면 프로그램의 Query Cost는 갈수록 뻗어 올라가고 어떤 미친놈은 전체 DB를 수차례 조인을 걸고 인덱스는 없거나 개판이고 등등등의 문제를 발생시키곤 하지요. 어떤 미친놈은 각 웹페이지별로 접근하는 사용자를 카운트하겠다고 동접 수천이 예상되는 각각의 페이지들에 들어가는 쿼리에서 row lock을 걸어버리는 짓을 하기도 하고 뭐..(가장 최근의 외주 개발자의 삽질이슈. 아놤 그것 좀 빼버려 ㅄ아~ -_-;)

하여간 덕분에 지금 있는 J 모사에 들어오자마자 DB서버 튜닝부터 삽질을 시작한 것을 필두로 별 되도않는 쿼리들을 보고 기가 막혀서 돌아가실 것 같은 기분이 막막 들기도 하고..OTL

하여간 신세한탄은 접고, linux ext3에서의 mount option에서의 noatime 사용시와 비사용시(default : atime)의 차이에 대한 이슈.

보편적인 사용에서는 크게 신경을 안쓸지도 모릅니다만, 되도않는 쿼리로 인한 무자비한 Multi Table Join 환경이라면 분명히 도움이 됩니다. 실제로 DB서비스가 운용이 거의 불가능한 수준에서 15krpm 20EA Raid 5 스토리지 구성으로 바꿨음에도 실제 서비스에서 사용자 부하 지속 발생시 iowait이 4~50% 이상 올라가는 문제가 발생하더군요. 쿼리 튜닝이 최종 답안이고 반드시 해야하기는 합니다만 이러저러한 이유로 그것이 힘든 경우라면(비지니스 로직상의 문제일수도 있고, 단순하게 쿼리를 뜯어고친다는 개념에서 벗어나 외주 개발로 인하여 쿼리의 비지니스 로직상에서의 역할이 파악되지 않는것의 문제일수도 있고, DB 구조 자체의 문제일수도 있고..그렇죠? 전 세가지가 다 꼬여있는 상황이었습니다만;;) 다른 방안을 생각할 수 밖에 없는 상황에 봉착. 결국 특단의 조치로써 noatime을 사용하기에 이릅니다.

용도는 아시다시피 access time 기록을 하지 않는 것. process에서 접근하면서 적어도 쓸데없이 써대는 것은 막자는것이죠. access time만 기록하지 않아도 read type의 프로세싱이라면 I/O 이슈에 대해서는 충분한 효과가 있을테니까요.

결과요? 4~50% 이상의 iowait을 기록하던 시스템이 sar 기록상의 10분 평균 평균 15% 남짓, peek minute 기준으로 봐도 20% 근방에서 머무는 시스템이 되었지요. select join 타입의 퍼포먼스에 대해서는 분명한 효과가 있다고 보면 됩니다.

트랜잭션 중첩과 경합의 문제만 없다면 오라클에서의 COMMIT_WRITE 역시 바꿔볼까 생각중입니다만, 서비스 오픈 준비중인 사이트의 각 리스트 페이지별로 박혀있는 바보같은 update/row lock 거는 쿼리 하나때문에 일단 잠시 보류중입니다. redo/undo log 컨트롤만 좀 더 가능하다면 트랜잭션 부하까지도 충분히 줄어들기 때문에 지금 계획중인 DB서버 교체계획도 좀 더 뒤로 미룰 수 있지 않을까 예상하고 있습니다. 물론 예상은 예상이고 산다는 것은 예상처럼 흘러가지 않기에 인생이 다이나믹한 것이지요.

외주 개발을 못하게 막아버려야 그나마 스트레스가 줄어들지 이거 -_-;;





tag : , , , , ,  ]]> Linux/IT/Geek DB oracle IO noatime commit_write performance http://ydhoney.egloos.com/1957958#comments Wed, 18 Nov 2009 08:24:16 GMT ydhoney <![CDATA[ 생보사들도 슬슬 상장을 시작하네요 ]]> http://ydhoney.egloos.com/1943812 http://ydhoney.egloos.com/1943812
삼성생명도 상장을 추진(이라고 하기엔 다소 떠밀리는듯한 인상이지만..)한다고 하네요.

네.

생보사가 증시에 뜹니다. 증시의 새로운 샛별이 되겠군요.

생보사야말로 무슨 은행이니 증권사니 이런 애들과는 비교도 되지 않는, 진정한 자본시장의 최고의 풍운아랄까요?

개인적으로 기대가 참 큽니다.

물론 차트는 보면서 해야겠지요 ^^

- 개인적으로 가치라는 측면에서 삼성생명보다는 동양생명이 더 끌리는 편이기는 합니다만 ^^ 그래도 주식이 가치대로 움직이지 않는다는 것을 감안하면 삼성생명이 대장이 되는건 기본이겠지요? 일단 생보사 중 가장 큰 회사기도 하고..일단 망하진 않을테니까요. :-) 솔직히 삼성전자가 망할지언정 삼성생명은 망하지 않을 것이라는 것은 당연지사가 아닐까 싶습니다. 혹시나 만일의 사태로 삼성그룹이 모두 무너져도 마지막까지 남을 것 역시 삼성생명이구요.

tag : , , ,  ]]> StockGuru 생명보험 상장 동양생명 삼성생명 http://ydhoney.egloos.com/1943812#comments Mon, 16 Nov 2009 03:41:45 GMT ydhoney <![CDATA[ 리눅스에서 대역별로 ping 스캔하는 법 ]]> http://ydhoney.egloos.com/1913226 http://ydhoney.egloos.com/1913226
그냥

nmap -sP xxx.xxx.xxx.0/24

이런 식으로 대역별로 Ping 스캔을 하세요.

기본적으로 ssh/telnet/netstat/ping/fping/nmap/nc/vi/gcc(혹은 perl이나 python) 만 있으면 인터페이스가 좀 하드해서 그렇지 뭐든 못할건 없겠잖아요?

그러다가 잡혀가도 모르겠습니다만 :-D (그러니까 스푸핑을 잘 해야..)

좀 더 깔끔한 리스트 정리가 필요하면 출력 옵션을 잘 맞춰서 쓰세요. (-o 계열 ^^ 개인적으로 -oX (XML)를 가장 선호합니다.)

GUI가 필요하면 zenmap을 쓰면 되겠지만..대체 GUI라는게 뭐한다고 필요하단 말인가요? (어?)

tag : , ,  ]]> Linux/IT/Geek ping scan nmap http://ydhoney.egloos.com/1913226#comments Sat, 14 Nov 2009 05:35:36 GMT ydhoney <![CDATA[ nginx는 정말 국내 사이트같은 복잡(조잡?)한 사이트에서는 쥐약인 듯 ]]> http://ydhoney.egloos.com/1899945 http://ydhoney.egloos.com/1899945
그냥 이미지서버나 스트리밍서버, Contents Delivery 서버 등에 한정해서 사용하는게 나은것이 아닌가 싶다.

정말 심플한 사이트라면 모르겠는데 조금 조잡해지거나 국산같이 뭔가 막 ucc가 돌아가고 거기에 뭐가 더 추가되고 등등등의 문제등을 쭈욱 겪다보면 꼭 자잘하게 한두개씩 안된다. 퍼포먼스는 매우 뛰어나나 기능상의 제한이 사용자의 발목을 잡는것이다.

하여간 이것때문에 요즘 좀 짜증이 샘솟을려고 하는 듯.

업로드를 순수 아파치 서버로 바꿔놓긴 했는데..

아 그러니까 플래쉬 게임을 왜 만들어서 사람 고생시키냐능 OTL;

mp3 호출을 그렇게 무지막지하고 무식하게 하는 게임을 만들어놔서는 서버 부하나 늘어나고 사람 짜증나게 정말;;

tag : ]]> Linux/IT/Geek nginx http://ydhoney.egloos.com/1899945#comments Fri, 13 Nov 2009 07:39:13 GMT ydhoney <![CDATA[ 소비와 소득의 사이클 우선순위 ]]> http://ydhoney.egloos.com/1899919 http://ydhoney.egloos.com/1899919 소비는 증가하고 소득은 줄어들어 실질소득이 최악이라는 이야기를 접할 수 있다.

근데 말이다. 소득이 늘고 소비가 느는게 아니라 소비가 늘고 소득이 늘어난다.

물가가 싸지고 구매 여력이 생기고 소비가 늘고, 소비가 늘면 매출이 늘고 생산이 활성화되고 재고가 줄고 기업이 활성화되고 월급이 늘고 고용이 늘고..

이러한 패턴으로 볼 때 저런 잡다한 기사는 별로 도움이 되지 않는다는걸 알 수 있다. :-)

소득과 소비 중 무엇이 우선인가를 잘 생각할 필요가 있다.


But, 카드 사용률 증가세가 더 가파르게 상승한다던지, 혹은 주구장창 소득 증가세가 이루어지지 않는다던지, 고용 증가등의 후속조치가 중장기적으로 함께 받쳐주지 않는다면 사상누각일 확률도 배제할 수는 없다. 하지만 기본적으로 얘들은 후행지표고 소비 등의 선행지표 대비 최소한 1년 이상의 후행성을 보이기 때문에 지금 당장 좋다 안좋다를 판단하기는 곤란하다.

그리고 실질소득 판단에 대한 통계치를 잘못 해석하는 오류가 있을 수 있는데, 시간당 실질소득의 전년대비 증가율의 추이를 살펴봐야지 분기별이라던지 절대적 수치라던지 그런 단순한 통계치 일부만을 가지고 판단하면 반드시 통계 해석에 오류가 생길 수 있으니 주의하자.





tag : ,  ]]> StockGuru 소비 소득 http://ydhoney.egloos.com/1899919#comments Fri, 13 Nov 2009 07:33:42 GMT ydhoney <![CDATA[ 인수 ]]> http://ydhoney.egloos.com/1897146 http://ydhoney.egloos.com/1897146
효성은 하이닉스 인수를 철회했습니다.

역시 외인들이 옳았네요.


2.

HP는 3com을 인수합니다.

막장이 막장을 인수하는군요.

tag : ,  ]]> StockGuru 인수 MnA http://ydhoney.egloos.com/1897146#comments Thu, 12 Nov 2009 03:44:30 GMT ydhoney <![CDATA[ 최근 경제이슈 및 증권이슈 몇가지 ]]> http://ydhoney.egloos.com/1895544 http://ydhoney.egloos.com/1895544
금이 움직이는 경로를 볼 것.

금을 지배하는 국가가 장기적으로 좋은 경제 성장률을 기록할 것이다.


2.

4/4분기 실적 관련 이슈와 경기지표 이야기들이 많은 편.

분명 이번 3/4분기 어닝 대비로 보면 힘든건 사실이지만 2008년 4/4분기 실적이나 경기지표들을 생각한다면, 전년도 대비 실적이나 경기지표는 예상만큼 그렇게 나쁘지도 않고, 언론에서 떠드는 더블딥이니 하는 등의 논란 역시 4/4분기보다는 내년 1/4분기 이후를 바라보고, 일단 4/4분기 소비지표 흐름을 살펴본 이후에나 이야기할만한 것들일 것.

하지만 개별적인 주식만을 보면 3/4분기 대비 4/4분기 증가종목/업종 군을 중심으로 보는것이 현재 시장에서는 확실히 먹혀들어가는 방법일테고, 그 중에서도 작년 동분기 대비 성장률 감안해서 직전 3/4분기와의 성장률 비교 역시 감안하는 것이 좋겠다. 지표는 하나는 매출액, 또 하나는 EPS..


3.

6~7월쯤에 같이 있는 분께 한번 이야기한 적이 있었지만, 철도주는 과거나 지금이나 미래로 보나 굉장히 매력적인 주식이나 국내에는 철도주가 상장되지 않아서 투자가 불가능한 상황이라서 개인적으로 매우 아쉽다고 생각하는 편이다.(물론 국내 철도 산업의 공공성을 위한 적자 감수는 감안할 문제지만..) 그리고 얼마전 버펫씨가 철도주에 거진 가진 재산을 몰빵을 했다. 실제로 인수라고 보는게 맞을듯 하던데..결국 버펫씨도 미국의 흔하디 흔한 초 거부들처럼 결국 철도산업에 매진하게 되는것인가? 라는 생각.


4.

일단 단기적으로는 환율과 유가 흐름을 좀 더 살펴볼 것.


5.

신소재, 2차전지, LED, 태양광

현재 가장 유망한 미래를 향한 테마군들이다.

이 중에서 실제로 수혜를 보는 종목과 아닌 종목을 잘 구분할 것.

그리고 대기업은 대기업대로 볼 필요가 있고, 중소기업은 중소기업대로 별개로 보고..

이 쪽은 매매대상이긴 하지만 오히려 단기 플레이라기보다는 2~3년 중장기 플레이로 보고 주봉으로 대응하는 것이 높은 수익(몇십배 레벨)을 올릴 수 있는 길이라고 본다. 그렇지 않으면 단기 흐름에 흔들려 얼마 손에 들어보지도 못하고 털릴 가능성이 크다. 물론 하다가 단기 급등으로 시세가 몰려버린다면 그때는 일봉 선에서 해결해야겠지만..


6.

정 안되면 쉬는것도 방법이다.

그렇다고 아예 손을 떼고 시장에서 관심을 두지 않는것은 문제가 있다.



7.

인플레이션이나 디플레이션이냐의 논란이 있는 편이다.

하지만 결정적인 것은, 이제 화폐가치로서의 인플레나 디플레를 이야기하기보다는, 실물이 시장을 지배하고 실물이 표준 화폐의 기능을 대신할 시대가 도래할 듯 하다는 것이다. 금본위 시대 이후로 달러본위시대, 그리고 이후에 뭐 유로화니 엔화니 위안화니 뭐가 후속이냐 말은 많은데, 내가 볼땐 어떤 화폐가 시대를 선도하기보다는 실물이 선도할 확률이 크다. 그게 금이 될수도 있고, 아니면 상품시장에서의 상품 가치가 화폐가치를 움직일 수도 있다. 핵심은 상품이고 금이고 석유일 것이다.


]]> StockGuru http://ydhoney.egloos.com/1895544#comments Wed, 11 Nov 2009 16:29:57 GMT ydhoney <![CDATA[ nginx쪽 web service/proxy 사용시 첨부파일 사용 문제 ]]> http://ydhoney.egloos.com/1888762 http://ydhoney.egloos.com/1888762
그럴때는 location 항목 하위에 client_max_body_size 항목을 추가해야 합니다. default size가 1m로 되어있어서 1Mbytes 이상의 용량을 업로드하려면 오류가 나게 되지요.

저는

client_max_body_size 1024m;

를 사용합니다. ^^ 각 서비스 특성별로 적절하게 맞춰서 사용하시기를 :-)


p.s

모 해외포럼에서 어떤 병진이 proxy 설정을 location 항목 상단(server나 http 수준)으로 빼라고 올려놨던데 그냥 씹으세요. -_-;

tag : , , , , ,  ]]> Linux/IT/Geek nginx web 413 entity 파일 첨부 http://ydhoney.egloos.com/1888762#comments Wed, 11 Nov 2009 05:33:55 GMT ydhoney <![CDATA[ ngnix는 restart 를 하면 한번에 안되고 두번에 걸쳐 해야해요 ]]> http://ydhoney.egloos.com/1888733 http://ydhoney.egloos.com/1888733
그러니까 그냥 편하게 stop하고 잠시 기다렸다가 start를 하는게 나아요.

그리고 혹시 모르니까 프로세스는 늘 확인해야해요. ^^


tag : ,  ]]> Linux/IT/Geek nginx process http://ydhoney.egloos.com/1888733#comments Wed, 11 Nov 2009 05:29:00 GMT ydhoney