목록전체글보기 (25)
지니워의 일상다반사
뭐에 홀린듯이 그간 잘 쓰던 테스트용 가상 리눅스 OS를 날려먹었다. VM으로 쓰던 Virtual Box를 버전업 하는 과정에서 vdi파일을 다른 곳으로 옮겨두기 위해서 잘라내기 & 복사하기를 했는데 복사가 되는 과정에서 esc를 눌러버렸다. vdi 파일은 증발 ^^...... ㅁㄴ이ㅏㅓ리ㅏㅓㄴ이ㅏ러미나ㅓ리ㅏㅁ니라ㅓ 허허허헝 ㅠㅠ 혹시나 하는 마음에 쓰레기통도 찾아봤지만 보이지 않았다. 에휴... VM(Virtual Machine)으로 주로 Virtual Box를 쓰는데 Vmware보다 가볍기도 하고 사용법이 간단하다. 하지만 이번에 버전업을 하면서 의아하게 느꼈던 점이 있는데 최신 버전(2013년 12월 3일 현재4.3.4)64bit OS에 대한 지원을 하지 않는 다는 것이다. 혹시나 싶어서 몇단계에 ..
어제 밤, 잠이 안와서 이리저리 뒤척이다가 새벽 세시쯤이 되어서야 잠이 들었는데 잠들고 얼마 있지 않아 slave server 중 한대에서 장애가 발생했다. 모니터링 하시는 분들이 대표님께 연락을 했고 대표님께서 일단 서버가 제대로 돌아가게끔 조치는 해두고 주무셨단다. 출근해서 db server의 log부터 살펴보았다. 이런 저런 error message들이 많이 나타나고 있었는데 인과관계를 잘 따져 이 error들이 나오게 된 근본문제를 찾기 시작했다. 발견. 서버를 재부팅하거나 mysql을 재시작 직후 event scheduler 를 실행하지 못했다는 로그를 발견했다. 이걸 단서로 원인을 찾기 시작. 1. DB에 접속한 다음 mysql 변수 중 event scheduler과 관련된 것이 있는지 찾아보..
회사의 테스트 서버가 위치하고 있는 사무실을 비워주게 되면서 그간 사용하던 테스트 서버를 철수하게 되었다. 개발자들이 개발에 사용하던 테스트 DB와 기타등등 필요한 것들을 다른 서버에 옮겨서 설치를 해주어야 했는데 마땅히 생각나는 서버가 없었다. 현재 사이트를 운용하는데 사용되는 웹서버들도 이래저래 필요에 의해 다른 용도로 활용하다보니 더이상 뺄 만한 여력도 없고... 그래서 처음 생각한 것이 PC한대에 리눅스를 설치하고 서버로 활용하는 것이었는데 리눅스 설치까지 완료했으나 패키지를 다운받을 수 있는 mirror사이트에 접속이 안되면서 슬슬 일이 꼬이기 시작했다. 인터넷은 연결되어 있었고 같은 repo정보를 가지고 있는 서버들은 괜찮은데 유독 이놈만 mirror 어쩌고 저쩌고 하면서 당췌 패키지를 다운 ..
어제에 이어 오늘도 DB에 관한 포스팅을 쓴다. 원래는 어제 포스팅 말미에 언급했던 것처럼 댓글에 DB튜닝의 결과를 적으려했으나 내용이 꽤 길어질 듯 하여 새롭게 포스팅을 작성한다. 일단 어제 걸어뒀던 delete작업은 약 세시간여만에 포기하기로 결정하고 프로세스를 kill해버렸다. '으잉?왜?????????????????????????????' 라고 생각할 수도 있겠다. delete작업을 중지했던 이유는 간단한데 시간이 엄청나게 오래걸리기 때문이었다. 이는 MySQL의 알고리즘 때문인데 데이터에 대한 작업 수행속도를 높이기 위해 Index를 설정해놓아도 테이블에서 일정 수치 이상의 데이터 조작이 감지되면 Index를 사용하지 않고 데이터를 모두 읽고 가공하려 하기 때문이다. 쉽게 이야기해서 100이라는..
DB용량이 하루가 다르게 커져가고 있다. 하루에 작성되는 글의 수도 엄청날 뿐더러 그것보다 더 많은 코멘트, 꽤나 많은 용량의 이미지와 플래시등과 같은 첨부파일 등등...블로그가 공개된 곳이다보니 DB규모를 정확하게 적을 순 없지만 테이블 하나의 크기가 거의 100G에 육박하는 것도 있으니 그 크기가 얼마나 큰지 대략 짐작이 갈 것이다. 문제는 DB의 크기가 커지다보니 컨트롤 하기가 힘들어질 뿐더러 결정적으로 하드 디스크용량의 문제때문에 어떻게든 튜닝포인트를 찾아 불필요한 Data를 삭제하여 용량을 확보하는 것이 시급한 문제로 부각되기 시작한 것이다. 회사에 DBA가 없기 때문에 이 문제는 개발자 한명이 진행을 하기로 했지만 SE가 강건너 불구경 할 수 있는 처지는 아니다. DB는 서버에 설치되어 있고 ..
It밥을 먹은지도 그럭저럭 몇년이 지났다. (실력은 크게 안늘어난건 함정 ㅠ) 그간 일을 하면서 키보드에 크게 불만을 느낀적이 없었는데 최근에 기계식 키보드 지름신이 강림하여 이것저것 알아본 끝에 결국 지르게 되었다. ### DK 9008 g2 pro 블루/그레이 투톤 키보드 ### 3주정도 이것저것 요모조모 따져보면서 키보드를 선정했는데 최종적으로 DK 9008 로 골랐다. 이녀석으로 선정한데에는 몇가지 이유가 있다. 1. 키캡을 따로 구매하지 않기 위해 처음 키보드를 구입할 때 제공되는 키캡은 PBT재질이어야 한다. 또한 각인방식은 스티커나 일반 각인 방식이 아닌 레이저각인이나 승화방식을 사용해야 한다. 2. 텐키는 꼭 있어야 한다. 어렸을때부터 텐키를 주욱 써왔기때문에 텐키리스 키보드는 불편하다. ..
세상에는 리눅스 서버를 다루는 많은 SE들이 있다. 다른 직업도 마찬가지겠지만 SE간의 실력차를 가늠할 수 있는 몇 가지가 있다. 물론 SE마다 그 기준이 차이가 있겠지만 실력차를 평가할 수 있는 스킬 중 하나가 '서버보안'이라는 부분에 대해서는 대부분 동의할 것이다. 그만큼 보안은 SE에게 중요한 것이며 보안을 빼고서 SE를 논할 수 없다고 할 수 있을 정도로 중요하다. 특히, 요즘엔 DDos나 해킹, 웹쉘(WebShell)등의 서버를 위협하는 공격수단이 날로 발전하고 있기 때문에 보안의 중요성은 점점 더 커지고 있다. 물론 원칙적으로 보안은 '보안관리자' 혹은 '보안전문가'가 담당하는 것이 맞다. 하지만 현업에 종사하면서 '보안관리자'나 '보안전문가'를 만나본 적이 없다. '보안담당자는 상상속의 인물..
지난달에 있었던 일이다.여느날처럼 서버들의 로그를 확인하던 중에 아래와 같은 로그를 발견했다. Aug 8 12:06:27 s9 kernel: usb 1-1.2: reset full speed USB device number 29 using ehci_hcdAug 8 12:06:40 s9 kernel: usb 1-1.2: USB disconnect, device number 29Aug 8 12:06:40 s9 kernel: usb 1-1.2: new full speed USB device number 30 using ehci_hcdAug 8 12:06:40 s9 kernel: usb 1-1.2: New USB device found, idVendor=0557, idProduct=2221Aug 8 12:06:..
모든 서버에 적용 가능한 최적화 된 설정. 과연 이런 설정이 존재할까?개인적으로 이러한 설정은 존재할 수 없다고 생각한다. 모든 것을 아우르기에는 변수가 너무 많고 '최적화'라는 목표에 대한 개인적인 시각차가 존재하기 때문이다. 예를 들어, 작은 쇼핑몰의 서버를 관리하는 SE와 대형 커뮤니티 사이트를 관리하는 SE에게'서버가 좀 더 원활하게 운영되도록 하려면 어느 정도 업그레이드를 해야 할까요?'라고 물었을 때, 동일한 대답이 나오기는 어려울 것이다. 작은 쇼핑몰 정도의 규모라면 쿼드코어 혹은 옥타코어 정도만 되어도 서버가 돌아가겠지만 대형 커뮤니티 사이트 같은 경우(뽐뿌, 디시, 일베, 오유, 웃대 등등)에는 (옥타코어 x 2) x 서버50대 ~ 100대 정도가 되어야 서비스가 돌아갈 것이다.즉, SE..
SE를 하기전에 짧지만 개발자를 했다. 변변찮은 프로젝트 하나 진행하지 못했지만 짧게나마 응용어플리케이션과 웹개발을 경험했었는데 그때의 경험이 SE업무에 큰 도움이 된다. 가령 개발자들이 요구하는 것들을 좀 더 빨리 알아들을 수 있고 그로 인해 SE가 할 수 있는 일과 할 수 없는 일을 빨리 판단하여 피드백을 해 줄 수 있다. 사소한 것처럼 보이지만 이런 작은 것 하나가 현업에서 인정받을 수 있는 센스중의 하나라고 생각한다. 조금전에 있었던 일이다. 관리하는 사이트의 특정 게시판에 들어가려고 하면 GET_LOCK ERROR를 보여주면서 접속이 안되는 현상이 발생했다. 사이트 관리를 하는 분이 개발자에게 해당 현상을 이야기했고 개발자는 나에게 이야기를 했다. 어라?그런데 이 GET_LOCK은 서버에서 내보..