박문형 2014-12

욕먹는 것을 두려워하지 마세요.

위의 사수도 모르는 일을 밑의 사람이 다 알수는 없는 일입니다..

사수가 있으니 보통 방어막은 됩니다.

잘리면 사수가 먼저 짤리지 밑의 사람부터 짜르지는 않지요..

전의 메일 문제건이였군요..
하드웨어 튜닝보다 소프트웨어 튜닝이 더 급한 것으로 보였는데
프로그램이 어떻게 동작하는지부터 아는 것이 중요합니다.

메일이 오면 그 사람으로 전해질 때 전의 모든 메일을 다 채크하고 메일이 전해지는 거 같은 느낌이였는데..
아무리 서버에 돈 처발라도 그건 어떻게 할 수가 없을 것으로 보여집니다..
(소프트웨어에서 잡아야 된다는 이야기)

신성공 2014-12

박문형 선배님 답변감사합니다.

메일주고 받고는 엄청 빠릅니다. 정말로요.1초이내에..이루어집니다.

근데 목록을 보여줄때의 페이징이 느립니다.....느리다못해 멈추고 응답없음까지 갑니다...껏다켜도 마찬가지라

타부서 사람들이 이제 불만이 터져나오고있어 서버 분리를 추진하거였는데.. 일이 더꼬여버렸습니다. 흑흑....

회원K 2014-12

2. MSSQL에서 어디서 느린지 확인해본결과 메일 7000개 이상되면 페이징해오는데 30초가 걸립니다.  개인당 1만개넘어가면 1분정도 나오더라구요. 물론 MSSQL내에서 select * from mail where = '계정 '쳤을경우

메일의 갯수를 저장해 둬야죠... 매번 full scan을 하면 부하가 당연히 걸립니다.
추가로 create tmpdb_user계정 select * from mail where = '계정' 이런식으로 db operation을 해서
tmpdb로 user set을 분리한 후에, 그 안에서 처리해야 균일한 속도가 나옵니다.
이런식의 엉성한 코딩과 DB 운용이 들어 있기 때문에, 건수가 늘어나면 속도가 느려지는 것 입니다.

부하가 걸리는 것은 slow query가 생기는 부분이 아니라 앞뒤의 부분에 기인할 수도 있기 때문에
전반적으로 시스템과 DB구조를 잘 이해해야지 튜닝이 가능한 겁니다.

이런 상태라면, 장비에 아무리 돈 부어봐야 성능 안나옵니다.

DB서버가 cpu 사용량 0%... 프로그램 이슈가 99.99%...

신성공 2014-12

답변감사합니다.
맞는거 같습니다. 기존에 누가 만들었는지는 모르겠지만...정말... 쿼리가 문제인거 같습니다.
전 서버 관리자인데... DB나 개발까지 도 떠안게 되서... 뭐가 먼지 하나도 모르겠습니다...
전산실은 모든것을 다잘해야 한다고 사수가 그랬는데... 저의 뇌용량이 작은지 한계를 많이 느끼고있습니다...
이젠 우울증까지도 오네요...DB기초도 없는데... 어떻게해야할지 난감하네요.

회원K 2014-12

프로그램의 구조를 모르겠지만,
메일서버에서 읽은 것은 모두 ms-sql db에 넣고 메일서버에서는 삭제를 해야죠.
- 예전에 돌렸었던 pop3 메일 관리자 시스템에서 그렇게 했었습니다. 속도는 광속이죠.

지금의 상황은 인터넷 검색해서 답을 copy & paste하는 모습입니다.
뭐가 뭔지 이해를 전혀 하지 못한 상황에서, 인터넷의 답이라는 것을 맹신한거에요.
해보면 알겠지만 인터넷의 system 지식 - 특히 naver 등의 지식 - 은 좀... 그런 것들 입니다.
급하게 누군가의 답을 가지고 내 것인양 포장해서 내밀기 때문에 문제가 생기는 것이구요.
서버와 시스템은 모르면 모른다고 해야 하고, 제대로 잘 알 때까지 나서면 안됩니다.

http://serverfault.com/
서버 지식의 시작이자 끝인 곳인데,
지금처럼 성급하게 피상적인 질문을하면 바로 벌점을 먹고 질문은 close 될 겁니다.

서버와 시스템 운용의 지식은 하루 이틀에 만들어지는 것도 아닌데
너무 성급하게 실적을 만들어 내려고 무릿수를 두는 것 같습니다.
그러면 credit만 떨어집니다.

박문형 2014-12

사람이란게 기계는 아니기에 모든 것을 다 잘 할수도 없습니다.

어떻게 돌아간다는 정도만 알면 됩니다.

모든 메일을 아마도 한 디렉토리에 쌓아 둘텐데 그곳은 캐쉬달린 레이드나 SSD로 되어 있지는 않겠지요?

그곳의 I/O를 빠르게 하면 되지만 돈이 지랄 같이 들테니 우선 소프트웨어 튜닝을 하는게 맞다고 봅니다.

신성공 2014-12

지금 현재는 SATA 2테라 하드에 첨부파일이 담아져있는 구조이며 폴더한곳에 계정별 폴더에 담아지며,
메일은 DB에 EML을 해독하여 저장되는 구조입니다.

소프트웨어 튜닝이라는게 DB튜닝을 말씀하시는거죠?

박문형 2014-12

소프트웨어 튜닝이란게 DB튜닝만은 아니라고 생각합니다.

전 소프트웨어 전혀 모르고 하드웨어의 일부만 하는 사람인지라..

2테라 하드 하나이고 그게 캐쉬 달린레이드 카드등을 거치지 않았다고 하면

하드 안 깨지는게 신기해보입니다..
(부하가 하나가 아니고 수십개가 들러 붙어서 벅벅거렸을텐데 무지무지 느려지죠)

캐쉬 달린 레이드 카드를 통하면 대략 3-5배 정도는 빨라지고 SSD로 바꾸면 더 빨라지겠죠.
(근데 돈이 무지 깨질 것입니다. 다 IBM장비로 보이니)

박 2014-12

3. 네트웍문제로보입니다. 아마도 스위치와의 연결이 반이중(half duplex)으로 된듯합니다.
이럴때는 알기쉽게 양단(서버및 스위치)모두 1000/full로 고정시켜보세요.

4. CAT5.E도 노이즈없는 일반사무실내/IDC 환경에서는 기가빗 통신 전혀 문제없습니다. 문제있어도 100MBps 는 나와야 합니다.

하드디스크도 가능하다면 더 늘리세요. 위에도 언급하셨듯이 쓰기속도때문에라도 1+0을 권장하며, 디스크갯수가 많을수록 IOP{S가 잘나옵니다. 쉽진않으시겠지만 SSD로 바꾸는것도 좋구요.

위기가 곧 기회입니다. 어렵고 힘들지만 도전해서 해결하면 자신감과 능력이 올라갑니다.포기하면 기회를 날리는거죠.
파이팅~

신성공 2014-12

답변감사합니다.
3번 문제는 확인 못해봤지만, 내일 출근해서 확인해보겟씁니다.
4번 문제 조언감사합니다. 이쪽은 걱정안해도 되겠군요. 또 의심할번했습니다. 히힛
하드디스크는... 더이상 확장이 불가능합니다. 이미 결제가 난상황인지라..
레이드 10 구성해보도록 노력해보겠습니다.

허걱.. 저희 팀장님하고 똑같은 말을 하시네요... 와 소름돕는다... 위기가 곧기회이다...
이거 저희 팀장님이 자주 하시는 말이거든요..... 조언 정말 감사합니다.

천외천oo노… 2014-12

제일 처음 올리셨던 질문글에 댓글에도 달았었습니다.
원격파일 접속에 문제가 있을 수 있다...라는 내용을 언급드렸었지요.
기본적으로 프로그램 코딩 문제입니다. 장비를 아무리 좋을 걸 가져다 넣어도 어쩔 수 없을 겁니다.

엠브리오 2014-12

길게 써 놓고 보니, 잘 알지도 못하는 Windows 시스템에 대해서
이러쿵 저러쿵 얘기만 늘어 놓고 정작 해결책을 내놓은 것도 아닌것 같아서..
썼다가 지웠네요. @@

그냥 저의 개인적인 의견만 슬쩍 적어 봅니다.

혼자서 해결될 문제는 아닌걸로 보입니다. 해당 시스템을 직접 들여다 보고 분석할수 있는 외부 전문가의 컨설팅이 필요해 보입니다. 사수 및 전산부서 책임자와 같이 논의해 보시길.

밥한끼 2014-12

DB index 작업이 필요해 보이네요. MSSQL의 경우 slow query 로그를 남기지 않나요?

밥한끼 2014-12

insert 보다 select where문에 더 많이 사용되는 필드가 있다면 index 작업을 시도해 보세요.

seiti쩜es 2014-12

+1

index 가 필요한것 같습니다..
그리고 ms sql 에 할당된 cpu 코어수를 늘려주심도...
더한다면 버퍼 혹은 메모리 설정도 더 크게...

데이터가 너무 많으면 이런경우가 있으니 페이징을 쓰시는것도..

밥한끼 2014-12

개인당 1만개 넘어갔을 경우 1분 넘는다는 것은 해당 테이블 전체 레코드가 아주 많아서 쿼리타임이 느릴 경우이거나 그렇지 않으면 가져오는 사용자단 화면의 프로그램이 잘못 설계되어 있어 그런 것 같습니다.

제 생각엔 해당 테이블의 전체 레코드수가 아주 많고 그 많은 부분에서 index없이 통으로 가져와 버리니 발생하는 문제인 것 같습니다. 우선 index로 해결해 보시고 어느정도 해결이 되었다면 메모리 증설을 고려해 보세요.

김윤술 2014-12

아이구 저말만 듣고 어뜨게 결론 냅니까. 정확하게 분석을 하지 않는 이상 넘겨 짚지 마세요.
대부분의 장애문제는 전문적인데서 발생하지 않고 아주 기본적인걸 간과해서 문제가 되는 케이스가 흔하다는걸 알아야 합니다.

밥한끼 2014-12

해답을 구하고 있는게 아니라 조언을 구하고 계신 것 같은데요. 여기 답변 중에서 해결책을 찾을 수도 있겠지요.

밥한끼 2014-12

그리고 단순히 메일 리스트를 가져오는 화면에서는 아래의 query보다는
select * from mail where = '계정'

필요한 필드를 지정해서 가져오세요.
select 필드1,필드2,필드3 from mail where = '계정'

꼴통황진우 2014-12

+1

Select * From mail where id ="계정"

이렇게 하시면 ID 만 검색 합니다.

아니면

Select * From mail where id ="계정" and data = "오늘날짜" or data = "어제날짜"

이렇게 하시면 오늘 날짜와 어제 날짜 메일만 검색 합니다...

luckyoo 2014-12

메일 7000개 이상되면 페이징해오는데 30초가 걸립니다.  개인당 1만개넘어가면 1분정도 나오더라구요.
--------------------------------------------------------------------------------
메일의 경우 한번에 전체 데이터를 가져올 필요가 없습니다.  최근순으로 일부만 보여주던가  범위를 지정해서 조회하지요.
또 , '계정' 으로 조건없이 all select 할 경우 7천건~1만건 이던 10건이던 full scan 이므로 속도가 다를 이유가 없습니다.
자료가 많을경우  버퍼가 오버해서 죽는게 아닌지 프로그램이나 통신 구간 단위로 정해진 버퍼 사이즈를 확인해 보시기 바랍니다.

향촌 2014-12

메일시스템만 개선하시면 해결될것으로 보입니다.
비슷한 그룹웨어 시스템을 본적이 있는데 POP3 방식으로 파싱하여 DB에 넣는 방식은 비추합니다.

실시간 메일이 수신되거나 송신될때 파싱하여 DB에 넣는 메일시스템을 이용하시고 그룹웨어에서는
필요한 페이지만큼만 불러서 뿌려주기 때문에 거의 속도 저하가 없습니다.

그리고 기존 메일처럼 수신된 메일이 한폴더에 존재하면 NTFS 파일시스템에서는 파일갯수가 많이 증가하면
응답속도가 많이 떨어집니다.
따라서 메일저장도 디렉토리가 다중화되는 메일시스템을 이용하십시오.

stone92 2014-12

기술적인 부분들에 대한 언급들이 많으니 저는 다른 이야기를 드려볼까 합니다.
본인이 현재 시스템을 잘 이해하고 있는가에 대해 잘 생각해 보시기 바랍니다
인터넷상의 조언들은 말그대로 조언일 뿐입니다.
본인 스스로 자기가 다뤄야 되는 시스템에 대해서 이해를 못한 상황에서 무작정 일을 만드는것은 본인 스스로의 함정에 빠지게 됩니다.
뭐 많은 경험을 가진 사람은 아니지만 몇년동안 전산관리자 일을 하면서 느낀 몇가지 조언을 드리자면 이렇습니다.

1. 시스템에 대해서 이해와 숙지가 필요합니다. 따라서 시스템을 만지기 시작한다면
그 시스템에서 운용되는 모든 것들에 대해서 학습이 먼저 선행이 되어야 합니다.
많은 프로그램들이 달려있는 상황에서 모든것을 전문가 수준으로 끌어올리기는 힘들지만 최소한 대략적인 구조와 기능을 파악한 후에 시스템을 만지시기 바랍니다.
눈앞에 보이는 문제를 당장 해결하기 위해서 이것저것 인터넷에서 얻은 지식으로 섯불리 시도하지 마시기 바랍니다.
오히려 독이 될 수 있습니다.

2.  계획성을 가지고 업무를 진행하십시요.
여기 계신분들이야 본인들의 경험과 학습의 결과를 말씀해주시기 때문에 님의 상황과 100% 맞을수는 없습니다.
따라서 시스템 개선 또는 문제 해결을 위해 하드웨어 업그레이드가 필요한지 프로그램의 수정이 필요한지에 등등에 대해서 먼저 검토를 하신 다음  시간은 최대한 여유있게 잡아서 진행하시기 바랍니다.
보통 저의 경우는 아래와 같이 진행합니다.
시스템파악->문제점 확인->기존시스템과 동일한 시스템 셋업->개선 작업 및 개선결과 확인->실 서버 적용
님의 경우 이런 일련의 과정이 하나도 없이 무작정 적용했기 때문에 오히려 문제 해결도 안되고 신뢰만 잃게 된것입니다.
제 경험을 이야기 해보자면 예전에 미국회사와 합병이 되면서 네트워크 통합 작업을 했는데 2개월 동안 컨퍼런스 콜만 하면서
네트워크 구성에 대해서 이야기 나누고 나서야 업무가 진행이 되었습니다.
실제로 네트워크 구성이 아주 복잡하고 어려운것이었냐 하면 답은 결코 아니었습니다.
미국 본사와 VPN으로 묶고 VOIP망과 인터넷망을 연결하는 것이었기 때문에 어려운 작업도 아니었지만
거기서 발생할 수 있는 많은 변수들을 검증하고 대책을 미리 마련하는데만 2개월의 시간이 걸렸습니다.
단순히 연결만 한다라고 하면 하루도 안걸리는 일이었겠지요...

3. 시스템 관리자는 끊임없이 공부해야 합니다.
시스템 관리자가 단순히 서버 장애 처리만 한다고 생각하시면 큰 오산입니다.
하드웨어 소프트웨어를 총망라해서 업무에 적용해야 되기 때문에 공부는 항상 해야 됩니다.
이쪽 바닥에 발들인지 10년정도 밖에 안되었지만 아직도 매일 3시간 이상은 공부를 하고 있습니다.
공부가 별것도 아닙니다. 하다못해 인터넷에서 정보 뒤적거리는것도 공부입니다.

4. 모든 작업의 결과는 문서화 시키고 사수한테 항상 메일 보고를 하십시요.
보고의 형태는 대충 이렇습니다.
무슨 무슨 작업을 했고 문제 해결을 위해서 필요한 부분들을 적으시고
본인이 모르는 부분에 대해서는 지시를 받지 마시고 물어보시기 바랍니다.
이런 경우 어떻게 진행해야 되는지 저런 경우 어떻게 진행해야 되는지 등등
물어보는데도 뭔가 자리때문에 정보를 주지않는 사수라면 그냥 나오세요...별로 도움되는 사람은 아닙니다.
뭔가 자기가 아는 정보가 진리인양 가지고 있으면서 의견을 나눌수 없는 사람이라면 실력이 뻔합니다.

5.  추측하지 마십시요.
이래서 문제가 아닐까 저래서 문제가 아닐까 생각하지 마십시요.
기계는 거짓말을 하지 않습니다. 원인을 본인의 눈으로 확인하고 검증하기 전에는 추측만으로 문제에 대해서 접근하시면 엉뚱한 곳에서 삽질을 하는 수가 있습니다.
경험이 좀더 쌓이면 당연히 저쪽은 문제없을꺼야 하고 추측하고 넘기게 되는데 가끔은 그런 추측때문에
몇날 며칠을 고생하는 수가 있습니다.

VINCENT 2014-12

+++1. 정말 좋은 말씀이십니다.
인터넷에서 얻는 정보는 그저 아이디어? 정도로만 생각하셔야 할 것 같습니다.
이미 내용은 다 잘 알고 있는데, 혹시 하나 빠뜨린 부분이 있을 때 그 부분에 대한 아이디어랄까?
전문 컨설턴트라고 해도 현장에서 다 까보지 않고서는 확실한 답을 만들 수 없을껍니다.

잔혹한마법사 2014-12

하드웨어쪽은 윗분들이 많이 얘기하셨으니..
저라면 확인해 보고 싶은 부분..

1. 7000개 쯤에서부터 느려지는 것이 뚜렷해 진다.
쿼리의 속도가 느린 것인가?
수천만건 정도 수준에서는 쿼리를 해 오는데는 시간이 별로 걸리지 않습니다. 더구나 where절에 들어가는 인자가 "계정"인데 이 경우 대체로 PK이기에 자동으로 인덱싱이 걸려있습니다.
DBMS에서 사용하는 메모리가 부족하지는 않은가?

2. DB에서 가져오는 데이터의 용량은 예상과 같은가?
화면 구성을 위한 최소 용량의 데이터만 가져오는가?
예상을 초과한 데이터가 발생하는가? 초과 한다면 얼마나 초과하는가?

3. \\네트워크\\ 경로 접속이 되지 않는다.
폴더를 사용하는 서비스에 적절한 권한은 주어졌는가?
공유 폴더에는 적절한 접근 권한이 설정되어 있는가?

4. 공유 폴더에서 복사하는 것도 느리다.
스토리지의 OS에서 네트워크 카드는 속도를 얼마짜리로 인식하고 있는가?
현재 인식한 네트워크의 대역폭중 얼마나 사용중인가?
스토리지의 각종 리소스중 90%를 넘게 사용중인 리소스가 있는가?

일단 당장 떠오르는 짚어보고 싶은 부분은 이정도네요.

--------------------------------------

이전 글에 너무 짧게 쓴 것 같아 이번엔 좀 길게 적어보겠습니다.

소스 분석이 먼저입니다. 라고 썼었는데요.
소프트웨어의 경우 하나의 일을 처리하기위해 수십개 이상의 처리 단계를 거칩니다. 그 중에서 병목현상이 발생하는 정확한 지점을 찾는 것이 우선입니다.
또한 원인을 찾았다고 해도 해법은 하나가 아닌 여러개가 존재할 수 있습니다.

마지막으로..
해결법을 근거로 문제를 재현해서 해결법이 맞다라는 것을 증명해야 합니다. 증명되지 않은 해결은 해결이 아닌 땜빵일 뿐입니다. 개발자들이 디버깅이라는 단어만 들어도 손이 떨리고 위가 아파지는 이유가 이때문이죠.

무아 2014-12

위에서 말씀하신 내용에 문제의 해결법이 거의 다 나왔을 것 같은데요.
일단 쿼리를 날렸을때 받아오는 데이터 량을 줄이기 위에 select * 대신 select 필요한필드,필드,필드  형식으로 쓸데없는 거는 가져오지않게 하고
날짜를 조건에 넣어서 7000개 이상의 결과가 나오지 않게 하면 쾌적해질 것 같은데요.
예전에 그냥 PC 에서 내부적으로 서버 만들고 APM 돌릴적에 7000개 정도 넘어가니 결과가 나오지 않더군요.