'2008/09'에 해당되는 글 7건
- 2008/09/26 바쁘다 바뻐 .. 에휴.. (1)
- 2008/09/19 2008 포카전 드뎌 오픈...
- 2008/09/18 Qdmail - PHP::Mail Library , Quick and Detailed for Multibyte
- 2008/09/18 아 서버세팅 힘드네 ㅠㅠ..
- 2008/09/16 MySQL 튜닝하기
- 2008/09/13 [2008-09-11] 베스 낚시.. 한번.. (1)
- 2008/09/09 GS칼텍스 고객 정보 유출.. 체크
정말 할일이 많구나 ...
얼마동안 머리가 아프게 생각하며 일을 추진하고 있다.
다 잘 되려고 노력하는 것이라서 몸이 힘든건 관계가 없다고 생각하지만
몸이 점점 나빠지는 것을 느낄 수 있다는...
휴...
서울 다녀 온 후로 목만 아프다가
이제 몸살까지 .. 요즘 일교차가 심하긴 한다 보다 ..
내가 몸이 좋지 않으면 마누라가 힘들어 하는데..
감기라도 옮기면 ㅠㅠ.. 어쩌지 흑..
어서 몸을 가다듬고 또 일에 매달려야 할텐데..
대학교며 이것 저것 이리 걸리는게 많은지원..
하나 하나 풀어 나가고 있다.
2008년이 얼마 남지 않았는데
할일은 쌓여 있는듯..
자~~ 대박 나리라~~
생각 하며 오늘도 코딩중... 쩝..
파이팅!
2008 포스텍-카이스트 학생대제전
 |
포카전 홈페이지
http://www.sciencewar.net/
대회 홈페이지
http://sciencewar.wowhacker.org/
드뎌 내일 고생한 보람이 있기를 ..
문제는 대회 홈페이지 시간표에 해킹 관련은 없다는거 ㅡ .ㅡ; 쩝..
우째 이런일이..
문제를 만드느라 고생한 WOWHACKER 팀에게 박수를...
포항공대랑 카이스트 해킹팀이 어떤 결과를 내 놓을지 너무 궁금..
위치는 잘 몰라 직접 가봐야 .. 알것 같음..
그럼
Qdmail - PHP::Mail Library , Quick and Detailed for Multibyte
PHP로 일본어 메일 관련 프로그램
http://hal456.net/qdmail/
SMTP 와 같이 사용하려면
http://hal456.net/qdsmtp/
일본어 홈페이지를 작성하면서
기본적으로 UTF-8 을 이용해서 홈페이지를 제작해 왔는데..
가장 걸림돌이 그놈의 메일 ㅠㅠ..
Yahoo Japan 의 메일에서 특정 문자가 깨지는 현상 - -..
짜증 지대로
또한 핸드폰으로 보낼때도 깨지고 .. 아주 돌아 버려 ..
그걸 말끔이 해결해주는 ㅠㅠ
일본 Google 검색을 생활화 해야 하나 .. 쩝..
오랫만에 하나 건져 봤넴..
김영준 선생님의 수능 무료강의 사이트 세팅하는중..
http://kimsem.org/
전 서버에 있으니 서버가 죽어가서
결국 서버 두대 구입
하나는 웹 서버 다른 하나는 디비서버로 꾸밀려다가
안되겠다 싶어 (접속자가 너무 많아서..)
체크 해 보니 디비 서버는 무리를 크게 주지 않아서
웹 서버를 두대로 세팅하기로 결정
RSYNC 를 이용해서 10분마다 동기화 시키고
로드발란싱 걸어 놓고...
한대는 웹서버+디비서버를 돌리는중..
대체적으로 아주 마음에 듬..
좋아 좋아 가는거야 ㅠㅠ..
아 지금 시간에 모 하고 있는지원
지금 시각 ㅠㅠ 새벽 3시 덴장 ㅠㅠ..
오늘도 이렇게 가는구나 ㅠㅠ..
아래 설정 값은
http://www.mysqlperformanceblog.com/ 를 참고하여 재 정리한 자료 입니다.
자신의 상황에 맞게 고쳐 쓸 필요가 있으며 실 서비스에 적용시 발생하는 문제에 대해서는 책임 지지 않습니다 . ^^;;
innodb_buffer_pool_size
인덱스와 데이터를 메모리로 캐쉬하기 위한 용도로 사용됨.
크게 잡을수록 Disk IO 가 적게 일어남.
최대 80% 까지를 추천
너무 크게 잡을 경우 OS 에서 사용하는 메모리가 적어져 스와핑이 발생하므로 주의 할 필요 있음.일부 보고에 의하면 50% 이상 잡더라도 실제로는 물리메모리의 50% 이상을 사용하지 않는다고 함. 따라서, 기본은 50% 를 추천함
innodb_flush_method
buffer pool size 와 관련된 중요한 설정값임
Innodb 가 이미 캐쉬한 자료를 OS 가 다시 캐쉬할지를 결정하는 설정값
Double buffering 과 스왑의 부담을 줄이기 위해 설정
Linux/Unix/Solaris/BSD 계열에서는 fsync() 를 사용하여 파일을 디스크에 Flush 함( InnoDB 가 기본적으로 사용하는 방법임). MySQL 의 쓰기 성능을 높이고자 할경우 O_DSYNC 로 설정할 수 있음. 윈도우 에서는 O_DSYNC 가 더 느릴 수 있음.
innodb_log_file_size
데이터 복구를 위하여 사용되는 로그파일의 크기
시스템 성능과 복구속도를 고려할때 256M 가 적당함.
innodb_log_buffer_size
대량의 blob 데이터를 Innodb 로 piping 하지 않는다면 4M 가 적당
innodb_flush_log_at_trx_commit
데이터 베이스의 ACID( Atomicity,Consistency,Isolation,Durability ) 를 고려하지 않거나 OS Fail시 트랜잭션을 보장하지 않을 경우 2 로 설정.
2로 설정하는 경우 짧으면서 대량의 트랜잭션 발생시 극적인 성능 향상이 기대된다.
MyISAM 엔진보다 100배 이상 느리다고 생각한다면 설정을 적극적으로 검토하라.
innodb_file_per_table
테이블 수가 지나치게 많지 않을 경우 사용
Innodb 메인 테이블스페이스를 사용 했을때의 관리 문제 극복 가능
thread_cache_size
스레드의 생성/소멸 에는 많은 비용이 드는데 이를 캐쉬에 저장하여 생성/소멸의 비용을 줄일 때 사용한다.
최소 16으로 설정하라.
query_cache_size
읽기가 집중적으로 일어나며 어플리케이션에서 캐쉬처리 하지 않을 경우 유용 너무 크게 잡으면 느려질 가능성이 있음.
범위는 32 ~ 512M 정도가 적당
출처 :
http://www.ihelpers.co.kr/programming/tipntech.php?CMD=view&TYPE=0&KEY=&SC=S&&CC=&PAGE=1&IDX=650
사장님과 함께 대청호로 베스 낚시 하러 ..
5시에 집에서 나와서 해장한번 하고..
6시 조금 넘은 시간 부터 오후 4시 넘게 까지 ... 휴..
이 보트를 타고....
조립하는게 장난이 아니더군 ㅡ.ㅡ;;
배에서 .. 한번 .. 표정 한번 잡아 보고 ...
생 초보가 첨으로 잡은 베스..
역시 작다 - -;;;
하지만 얼마 지나지 안아서 .. 3자가 .. ㅋㅋㅋ..
나 힘들어 보이나??
저렇게 잡느라고 왼손 엄지가 너무 아팠다는...
흑..
작은놈 하나 3자 4놈 총 5놈을 잡았다는..
처음 하는 것 치곤 잘 하지 않았나 - -;;
점심은.. 맥주와 김밥...
그늘에서 맥주와 먹는 김밥이란.. ㅋ ㅑ 아... 최고의 맛~~~
Prev
