현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

프로그램에서 I/O 사용량을 측정 할 수 있는 툴?

antz의 이미지
글쓴이: antz / 작성시간: 수, 2004/03/24 - 6:44오후

제가 관리하고 있는 검색엔진 프로그램을 분석중입니다.

이쪽을 잘 알지 못해서 궁금한 점도 많고,
난감하기도 하네요.

하나 하나 답변을 부탁드립니다.

첫번째 질문은 프로그램 보다는 시스템쪽입니다.

질문1) SCSI 서버보다 개발 PC가 4배나 검색속도가 빨랐다.
다음 사양으로 그럴 수 있는지???

컴팩서버 :
2 CPU, 펜3, 1133Mhz, 2G메모리, SCSI하드

Quote:
# hdparm -t /dev/sda
Timing buffered disk reads: 64 MB in 1.25 seconds = 51.20 MB/sec
# hdparm -T /dev/sda
Timing buffer-cache reads: 128 MB in 0.32 seconds =400.00 MB/sec

개발 PC :
1 CPU, 펜4, 2.8G, 1G메모리, E-IDE하드
Quote:
# hdparm -t /dev/hda
Timing buffered disk reads: 64 MB in 1.14 seconds = 56.14 MB/sec
# hdparm -T /dev/hda
Timing buffer-cache reads: 128 MB in 0.25 seconds =512.00 MB/sec

개발 PC가 컴팩서버보다 시간당 검색개수가 4배 이상 많았습니다.

좀 이해가 안되는 결과였구요.

둘째 질문은 검색엔진이 DISK I/O를 많이 사용해서 검색 결과가 느리게 나온다고 판단을 해서 구체적으로 어느정도로 I/O를 사용하는지 확인해 보려고 했습니다.

질문2) DISK I/O 사용율을 알 수 있는 방법이 있나요?

현재 iostat, vmstat를 사용해서 I/O를 비교해보려고 했는데...
hdparm에서 test를 하면 Read쪽과 CS쪽이 올라가는것을 볼 수 있는데...

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0  39516 181336 157640 582376    0    0 12736     0  303   450  0  4 96  0
 0  0  39516 182320 157704 582376    0    0 52800    37  937  1747  1 20 79  0

다음은 검색엔진에 동시 사용 100User 를 했을때
vmstat를 capture한것 입니다.

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 3  0  39516 161460 157148 582340    0    0     0     0  105   153 64 36  0  0
 4  0  39516 159728 157148 582340    0    0     0     0  104   125 69 31  0  0
 5  0  39516 172492 157156 582344    0    0     0   109  110   185 63 37  0  0
 4  0  39516 161320 157156 582344    0    0     0     0  106   136 55 45  0  0
 4  0  39516 172204 157156 582348    0    0     0     0  103   218 78 22  0  0
 3  0  39516 158400 157156 582352    0    0     0     0  104   213 65 35  0  0
 5  0  39516 138556 157156 582356    0    0     0     0  105   229 59 41  0  0
 4  0  39516 170208 157160 582356    0    0     0   109  116   216 71 29  0  0
 3  0  39516 171928 157160 582360    0    0     0     0  107   180 57 43  0  0
 4  0  39516 161784 157160 582364    0    0     0     0  104   227 62 38  0  0
 5  0  39516 175456 157160 582368    0    0     0     0  103   221 65 35  0  0
 6  0  39516 176996 157160 582368    0    0     0     0  103   186 66 34  0  0
 5  0  39516 164748 157172 582372    0    0     0   109  110   289 43 57  0  0

검색엔진은 Read쪽이 올라가지 않고, CS 쪽이 200정도 올라가는 것을 볼 수 있었습니다.

top으로 보면 검색엔진 process가 몇십메가씩 증가했다가
사라지는것은 볼 수 있습니다.

검색엔진이 1G정도의 데이터와 19G정도의 index를 가지고 있어서 I/O가 많이(그중 read가...) 생길거라고 생각했는데 그게 아닌건 가요???

질문3) CS가 올라간다는것은 어떤것을 의미하나요? 성능저하, 줄일수있나?

CS를 줄일 수 있는 방법이 있나요?
CS가 어떤것에서 많이 일어난다면,
그 어떤것을 되도록 안사용하면 안올라갈텐데요.

마지막 질문은 현재 단일 프로세스와 멀티쓰레드 풀이 속도에 차이가 없었습니다.
어떤면에서는 단일 프로세스가 경합이 없어서 안정적이었습니다.

다음은 검색처리속도에대한 thread pool 버전의 처리개수와
OneProcess버전의 처리개수 입니다.

처리속도 : 0.00057
Pool	OneProcess
2322.1    1531
2275.2    1506.8
2056.4    1510.8
2095.6    1539.7

처리속도 :0.00124      
Pool	OneProcess
849.8      729.9
892.8      731.9

처리속도: 0.08587
Pool	OneProcess
12.7        14.3
12.4        14.6

결과로 보면, thread pooling 방식을 사용해서 효과를 보려면,
처리속도가 0.00124 이상 되야지 된다는것을 볼 수 있었습니다.
처리속도가 0.08587 일때는 오히려 OneProcess의 처리개수가 2개정도
많은것을 볼 수 있었습니다.
0.00057 : ping 만했을때 응답속도
0.00124 : 검색결과가 검색속도가 빠른쿼리
0.08587 : 검색속도가 보통인 쿼리

질문4) 멀티쓰레드 풀이 성능을 못내는 이유가 뭘까요?

위 정보가 부족합니다만, 답변을 부탁드리겠습니다.

처리속도개선이 없으면, thread pool을 사용 하지 않는것이 맞는것
같은데 맞는지요? 처리속도에 영향을 주는것이 디스크 I/O라고
믿고있습니다. 혹시 의심 가는곳이 있는지요?

조언을 부탁드립니다.
감사합니다.

File attachments: 
첨부파일 크기
Plain text icon develpc.dmesg.txt6.5 KB
Plain text icon compaq.dmesg.txt15.01 KB
Plain text icon SearchBackd.profile.txt22.96 KB
Forums: 
프로그래밍 QnA
liongo의 이미지

글쓴이: liongo / 작성시간: 수, 2004/03/24 - 7:01오후

흐음 지나가다 흥미로와서 한글적습니다..

디스크속도를 떠나서 검색속도가 개발컴이 더빠른건

CPU 속도차이가 마니나네요 -_-

1기가 듀얼 씨피유라고 2기가의 속도가 나오는것은 아니니까요..

1기가 10개가 있어도 속도는 1기가의 속도가 나옵니다..

병목이 걸리기 시작하면서.. 듀얼시피유의 성능이 발휘되는것이죠..

파일 읽는 속도도 있겠지만 파일을 읽은후 버퍼에서 문자열을

찾아내는 부분에서 씨피유의 성능차이가 다소 나는것같습니다..

씨피유가 같아야 성능 비교가 공평할것 같습니다 ^^

그리고 멀티 쓰레드풀데 대해선..

무조건 쓰레드풀이 빠르진 않습니다 물론 부하가 걸렸을경우..

쓰레드풀이 처리량이 떨어진다면.. 그건 코드에 문제가 있는거같구요..

간단히 이야기하자만 단순 처리속도는 단일 프로세스가

더 빠릅니다.. 처리량을 늘려보면서 좀더 테스트를 해봐야겠습니다..

에고 별로 도움이 안되는글이되는 ^^ 이만 줄입니다..

' 형식이 내용을 규정한다. '

antz의 이미지

글쓴이: antz / 작성시간: 목, 2004/03/25 - 7:57오전

liongo wrote:
씨피유가 같아야 성능 비교가 공평할것 같습니다 ^^

글쓰면서 두 컴퓨터의 CPU을 비교해 보게 되었네요. ^^;;;
CPU차이가 많이 나네요.
속도가 복합적으로 차이가 나겠는데요.
여러가지 측면으로 분석을 할 수 있는 툴이 있을까요?

가령, I/O를 얼마나 사용했다. 시간으로 보면 전체 시간의 몇 %이다.
CPU는 얼마나 사용했다. 시간으로 보면 전체 시간의 몇 %이다.

이런것들을 알 수 있는 툴요.

똑같은 사양이 어려우니,
툴이 있다면, 상대적으로 평가를 해야겠습니다.

liongo wrote:
무조건 쓰레드풀이 빠르진 않습니다 물론 부하가 걸렸을경우..
쓰레드풀이 처리량이 떨어진다면.. 그건 코드에 문제가 있는거같구요..

부하라면 어떤것을 말씀하시나요???

전 지금 검색엔진에서 쓰레드 풀이 제 기능을 발휘하지 못하는 이유를
Disk I/O를 많이 사용해서 라고 가정하고 있습니다.
막말로, 계산처리가 1%이고 디스크 I/O가 99%라고
생각하고 thread pool을 생각하면, thread pool을
쓰는 의미가 없어진다고 생각하고 있습니다만,
어디까지나 개인적인 생각이라...

이 분야에 좋은 책이 있으면,
부탁드리겠습니다.

Lum7671's Weblog

liongo의 이미지

글쓴이: liongo / 작성시간: 목, 2004/03/25 - 11:15오전

개발환경이 SourceForge나 Freshmeat 사이트에 가셔서

profiler로 검색하시면 프로젝트가 몇개 나오는군요..

profiler로 이용하셔서 function의 호출수나 총 걸리는 시간등이

나오는것으로 예측이 가능할것같습니다.. 정확히 해당 process

가 사용한 disk i/o를 측정해주는 툴이 있는지는 모르겠습니다..

하지만 profiler만으로도.. 요청수에 비례하여 디스크 관련 system cal

l의 수나 걸린시간으로 추측이 가능할것같습니다.

그리고 제가말한 부하의 의미는 별다른의미는 없고 일반적인

쓰레드풀이 성능을 발휘하기위한 시점을 말하는거지요...

물론 디스크 부하일경우 대부분의 대기 상태가 디스크에서 걸린다면..

쓰레드풀이 성능이 나오지 않겠지요.. :wink:

디스크 부하때문에 쓰레드풀성능이 나오지 않는게 명백하다면..

제가보기엔 dist hits 수를 줄이기위해서 cache를 이용하셔야할것같아요..

메모리가 2기가가되니까 검색전용머신이라면 남는메모리를

캐쉬로 이용하셔서 디스크 i/o를 감소시키면 충분한 성능향상이

기대됩니다.. ^^

서적은 추천할만한 서적을 뭘해드려야할지 Thread 관련도 좋겠지만..

디스크 I/o가 높다면.. 검색속도 향상을 위한 알고리즘 분야아닐까요?

현상황에선 Cache성능이 매우 필요할것같습니다.. 에효 현재 정확히

어떤 구조인지는 모르겠지만 매번 디스크를 검색하는거는 비효율적

인것같습니다.. 검색에 맞는 캐쉬알고리즘을 적용해보세요~

그럼 이만 ~

' 형식이 내용을 규정한다. '

dudungsil의 이미지

글쓴이: dudungsil / 작성시간: 목, 2004/03/25 - 11:26오전

1. SCSI가 반드시 빠르지만은 않습니다. 그 구체적인 내용까지도 적어 주셨군요.

Quote:
SCSI
# hdparm -t /dev/sda
Timing buffered disk reads: 64 MB in 1.25 seconds = 51.20 MB/sec
# hdparm -T /dev/sda
Timing buffer-cache reads: 128 MB in 0.32 seconds =400.00 MB/sec

Quote:
IDE
# hdparm -t /dev/hda
Timing buffered disk reads: 64 MB in 1.14 seconds = 56.14 MB/sec
# hdparm -T /dev/hda
Timing buffer-cache reads: 128 MB in 0.25 seconds =512.00 MB/sec

buffer-cache reads의 경우에는 IDE가 25% 이상이나 빠르군요. 더구나 씨피유는 더블스코어 입니다. 개발 피씨가 월등한 속도를 내는건 당연합니다. SCSI RAID는 속도도 속도지만 복구를 위해서 사용한다는 말도 타당할겁니다. 컴팩서버 SCSI 하드의 스펙을 한번 살펴보세요.

2.
검색 서버가 작동을 하니 당연히 Read가 올라가구요. 전체적인 글의 내용을 볼때 쓰레드풀을 사용하는 것 같네요. CS는 Context Switching입니다. 쓰레드의 수가 많아지니 CS도 덩달아 늘어 나겠죠.

Quote:
검색엔진은 Read쪽이 올라가지 않고, CS 쪽이 200정도 올라가는 것을 볼 수 있었습니다.

CS는 증가하는데 Read는 더 이상 올라가지 않는다는건 Read가 한계에 도달했거나 더 이상 Read할게 없다는 의미겠지요. 더 많은 수의 유저가 검색을 수행하도록 테스트 해보시고 read값을 비교해보시면 어떤 상황인지 알수 있을것 같습니다.

3.
Context Switching이 많이 일어난다는건 그 순간에 cpu에 구애를 하는 thread의 수가 많다는 의미 입니다. 프로그램의 구조에 따라 다르니 CS가 성능을 결정할수는 없겠지만 필요이상으로 많다면 그건 확실히 성능 저하의 원인이 되기는 합니다.

풀과 원프로세스의 처리개수에서 중요한 내용이 빠졌습니다. 저때 풀에 작동중인 평균 쓰레드가 몇개인지를 알아 보셔야 할것 같습니다. 처리속도가 빠르다는 말을 다시 말하면 작동하고 있는 쓰레드의 개수가 적다는 의미입니다. 일을 빨리 끝내고 그 쓰레드가 다시 재사용되겠죠. 일반적인 경우에 처리 시간이 오래 걸리면 응답을 하기 위해서 새로운 쓰레드를 또 할당합니다. 그래서 쓰레드 수가 점점 더 많아 지고 CS수가 급증하게 되죠. 그러다 보면 쓰레드끼리 쌈질 하다가 볼장 다 봐버리는겁니다. 그래서 결국 성능이 역전 되어 버리는겁니다. 성능 평가를 해보시고 최적의 쓰레드 개수를 파악하셔서 그 선을 유지하도록 만드시면 OneProcess에게 추월 당하는 수모를 격지는 않을겁니다.

4.
3번에 어느정도 답변이 됐다고 생각합니다.

기타등등:
사실 저는 검색 엔진은 만들어 본적이 없을뿐더러 윈도우쪽으로 이사한지 꽤 되서 현재 상황을 정확히 예측하지는 못할겁니다. 몇가지 질문겸 힌트가 될만한걸 여쭤보고 싶습니다.

글을 읽어 보니 1유저당(정확히 말하면 1쿼리겠죠) 1쓰레드가 생성되서 처리를 하는것 같습니다. 이말을 바꿔 말하면 10만명이 동시에 쿼리를 하면 쓰레드 10만개를 만들려고 시도한다는것과 같은 말입니다. (물론 이렇게 되지는 않겠지만요) 쓰레드를 계속해서 새로 만들기 때문에 풀이고 뭐고 성능저하말고는 아무것도 없게됩니다.

이런 경우에는 보통 메시지 큐를 생성해서 전체적인 쓰레드 개수를 일정수준에서 유지되도록 합니다. 3번에서 설명을 드린것 같구요.

윈도우쪽 같은 경우 DevPartner나 vTune같은 걸출한 녀석이 있어서 이런 문제를 쉽게 찾을수 있습니다만 위에 말씀드린것처럼 linux(unix) 계열과는 좀 덜친해서 어떤 도구가 있는지 모르겠습니다.

생각나는 한가지 방법은 개발 pc의 cpu 사양을 낮춰보는 겁니다. 무려 2.8G나 되니 이게 cpu때문인지 io때문인지 파악이 안되는거자나요. 씨피유를 좀 낮은걸로 바꿔보세요. 그리고 성능 평가를 해보면 cpu가 미치는 영향을 파악해 볼수 있을겁니다.

ps. 2.8이면 HT아닌가요? OS에서 HT를 지원하고 있다면 컴팩서버에서 cpu가 두개박혀 있더라도 개발pc에 비해서 나은점이 전혀 없는겁니다.

산넘어 산

antz의 이미지

글쓴이: antz / 작성시간: 목, 2004/03/25 - 11:28오전

부족한 제 설명에
자세한 답변 감사드립니다.

profiler 제가 원하던 툴인것 같습니다.
한번 사용해 보겠습니다.

감사합니다.

케쉬관련, 알고리즘 관련은 어떻게 공부하는게 좋을까요. (좋은 책이라도...)
index가 19G라 메모리 2기가에 전부 넣을 수는 없을것 같고, 일부만 넣는다해도... 사용이 많은 걸 넣는건지?
이런경우 효율적으로 하는 방식이 있는지 궁금해 집니다.

다시한번, 답변 감사드립니다. :D

Lum7671's Weblog

antz의 이미지

글쓴이: antz / 작성시간: 목, 2004/03/25 - 11:45오전

긴 답변 감사드립니다. :)

많은 도움이 되고 있습니다.

dudungsil wrote:

ps. 2.8이면 HT아닌가요? OS에서 HT를 지원하고 있다면 컴팩서버에서 cpu가 두개박혀 있더라도 개발pc에 비해서 나은점이 전혀 없는겁니다.

HT란? Hyper Threading 인가요?

각각 사양에 대해 dmesg를 첨부했습니다.

감사합니다.

댓글 첨부 파일: 
첨부파일 크기
Plain text icon 0바이트
Plain text icon 0바이트

Lum7671's Weblog

liongo의 이미지

글쓴이: liongo / 작성시간: 목, 2004/03/25 - 11:45오전

휴우 저도 검색서비스 관련 작업할일이 없어서..

추천할만한 책까진 없구요 참고만 하시라고 한글 적습니다..

일반적으로 무조건 파일시스템으로 하셔야하는지 모르겠지만..

(현재 어떤정보 관련 검색이나 구조를 몰라서 ^^)

일단 현재 파일로 되있는것이라변 DB로 컨버팅 하셔서 해보는것이나

Database 설계나 관련 분야를 보시는것이 좋을것 같습니다..

현재 구조를 Mysql DB로만 옮기시고 스키마만 잘잡으셔도..

속도향상이 있으리라 봅니다..

기본적으로 DB란게 이미 하시려는 일을 위해서 만들어져있다고해도

과언이 아니니까요 ^^ 캐쉬기능 뿐만 아니라 관련 수많은 기술이

들어가있지요 ^^ 그럼
그럼 :o

' 형식이 내용을 규정한다. '

dyaus의 이미지

글쓴이: dyaus / 작성시간: 목, 2004/03/25 - 2:13오후

DB를 이용한 검색엔진 구상은 가능할 지 모르겠지만.
서비스에 적용할 수준으로 이용하기는 힘들것 같습니다.

full text indexing + @ 가 지원되어야 검색엔진으로서 동작할텐데.

아직까지는 그 성능이 원하는 수준이 안되는 것으로 알고 있습니다.

구글에서 서비스하는데 사용되는 장비수가 만대 정도라고 알고 있고.
10억 페이지 이상이 저장되어 있다고 알고 있습니다.

단어 수준에서 생각해야 가능한 것이라서, 여러가지 다른 방법이 있다고 합니다.

http://www.ils.unc.edu/~junliang/resources/indexing/tools_indexing_searchengine.html

antz의 이미지

글쓴이: antz / 작성시간: 목, 2004/03/25 - 3:42오후

GNU의 binutils 안에 gprof라는 프로그램이
있군요.

제가 원하는 결과를 대충 뽑아냈습니다.
검색쿼리중 검색시간이 오래걸리는 쿼리로 했습니다.

결과로 보면, 검색엔진이 CPU에 영향이 많은것 같습니다. :?

고민을 해봐야겠습니다.

혹시 필요하신 분이 있으실것 같아서 간단하게
gprof의 사용방법을 "자유강좌,팁" 에 올려놓겠습니다.

댓글 첨부 파일: 
첨부파일 크기
Plain text icon 0바이트

Lum7671's Weblog

liongo의 이미지

글쓴이: liongo / 작성시간: 목, 2004/03/25 - 4:50오후 

DB를 이용한 검색엔진 구상은 가능할 지 모르겠지만. 
서비스에 적용할 수준으로 이용하기는 힘들것 같습니다. 

full text indexing + @ 가 지원되어야 검색엔진으로서 동작할텐데

그렇겠죠..^^ 저는 질의하신분이.. 정확히 어떤 검색인지 언급이 없으시고

질의도중 index를 검색한다고 하셔서 key검색같은걸 생각했는데..

지금보니 해깔릴수있군요.. ^^

웹페이지 검색일 기준으로 말한것은 아닙니다..

정확히 어떤검색엔진인지 모르고 글을 써버렸네용 정정합니다 ^^;;;

그런데 구굴이 10억페이지에.. 만대서버라 장난 아니군요.. 처음들었습니다..

예전에 얼핏들었을땐 야후도 몇백대로 들은것같은데.. 휴우.~

구글이 램디스크를 쓴다고 들엇는데.. 그래서 빠르다고 생각했눈데..

대수로만 밀어도 장난 아니군요 ㅡㅡa

' 형식이 내용을 규정한다. '

antz의 이미지

글쓴이: antz / 작성시간: 목, 2004/03/25 - 5:44오후

제가 검색엔진 이라고만 해서,
오해가 생긴것 같아서 죄송합니다.

지금 하고 있는 검색엔진은 전화번호부 검색입니다.

인명에대한 검색, 상호에대한 검색, 업종에대한검색, 키워드에 의한 검색, 전화번호에 대한 검색
대충 이정도네요.
건수는 2600만건 정도 되고요.

처음 설계는 제가 한것은 아니구요.
속도를 생각해서 파일시스템으로 구성하셨다고 합니다.

다음을 봐주세요.
검색하는 루틴에서 시간이 많이 걸리는 군요. 

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 50.00      0.18     0.18   560596     0.32     0.32  HashFind
 27.78      0.28     0.10   560596     0.18     0.18  BTreeFind
 11.11      0.32     0.04    71912     0.56     0.56  HashInsert
  5.56      0.34     0.02       60   333.33   333.33  BTreeRemoveAll
  2.78      0.35     0.01    71281     0.14     0.14  AddClassList
  2.78      0.36     0.01        2  5000.00 169656.51  getListDoubleBuffer
  0.00      0.36     0.00    71912     0.00     0.00  BTreeInsert
  0.00      0.36     0.00    71279     0.00     0.00  AllocMemory
  0.00      0.36     0.00     1424     0.00     0.00  MEMSWAP
  0.00      0.36     0.00      231     0.00     0.00  CheckSize
  0.00      0.36     0.00      195     0.00     0.00  AddFieldString
  0.00      0.36     0.00       35     0.00     0.00  AddFieldInteger
  0.00      0.36     0.00       18     0.00     0.00  GetField
  0.00      0.36     0.00       12     0.00     0.00  pmkdir
  0.00      0.36     0.00        7     0.00     0.00  CommonLog
  0.00      0.36     0.00        4     0.00     0.00  FreeMemory
  0.00      0.36     0.00        4     0.00     0.00  SearchIndex
  0.00      0.36     0.00        3     0.00     0.00  Receive

이제부터 하나하나 따져 보겠지만,

위 결과를 보시고 조언 부탁드리겠습니다.

Lum7671's Weblog

lunarainbow의 이미지

글쓴이: lunarainbow / 작성시간: 목, 2004/03/25 - 9:57오후

mollla wrote:
결과로 보면, 검색엔진이 CPU에 영향이 많은것 같습니다. :?

검색엔진은 당연히 CPU에 많은 영향을 받습니다.

간혹 검색 사이트에서 보면, "0.XX 초 걸림" 하는 메세지를 보여주는 부분이 있을 것입니다.

만약 생각하시는것 만큼 I/O가 많이 일어난다면, 과연 저 시간이 나올 수 있을까요? :wink:

검색엔진에서 I/O가 일어나는 부분은,

단어 리스트 가져오는 부분과 앞의 데이터를 기반으로 추출할 문서번호를 계산한 후, 계산된 문서를 읽어올때 일어납니다.

이때 가져올 문서를 뽑아 내는 계산이 오래 걸리게 됩니다.
(문서가 만단위도 아니고, 수천만~억단위로 올라가는데, 이중 "담배"라는 단어를 가진 문서들의 수가 몇개나 될까요? 게다가 and 연산등이라도 들어갔다면... :twisted: )

검색 엔진은 "색인"이라는 시간이 있는데, 이때 필요한 대부분의 것들을 모두 계산해 둠으로써, 실제 검색시에 최대한의 성능을 내도록 설계되어 있습니다.

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.