'Know'에 해당되는 글 83건

  1. 2015.10.26 Install Docker for Windows
  2. 2015.05.11 MySQL Yum Repository
  3. 2015.05.06 IE에서 Websocket 연결시 12057 에러 발생시
  4. 2015.05.06 VirtualBox CentOS 게스트 확장 설치
  5. 2014.01.22 Netty ChannelGroup
  6. 2013.09.13 Memcached 내부 동작 원리
  7. 2013.09.13 Memcached Protocol document
  8. 2013.06.11 Selenium을 이용한 UI 테스트
  9. 2013.02.22 JDBC 동작 원리
  10. 2013.02.13 Java Troubleshooting Tool - VisualVM

Install Docker for Windows

Know/ETC 2015.10.26 15:11


Docker를 Windows에 설치할 경우, default machine을 실행하지 못하고, 

에러코드 255나 1로 exit되는 경우가 있다.


Error setting up host only network on machine start: exit status 1

Unexpected error getting machine url: exit status 255

VM이 활성화 되어 있지 않거나, 

BIOS의 virtualization 옵션이 활성화 되어 있지 않을 경우 에러가 난다.

BIOS로 진입하여 해당 옵션을 enable로 활성화 시킬 경우, 정상적으로 Docker가 실행된다.

windows7일 경우 아래의 링크에서 HAV detection tool을 다운로드받아 실행하여 체크.


'Know > ETC' 카테고리의 다른 글

Install Docker for Windows  (0) 2015.10.26
youtube developer api  (0) 2009.06.30
소켓통신 참조  (0) 2006.10.23
[펌] Web 2.0 Conference Korea 발표 B/S  (0) 2006.08.10
WinCVS의 간략한 사용방법  (0) 2005.11.14
노출된 정보 최소화하기  (0) 2005.11.11
Trackbacks 1 : Comments 0

MySQL Yum Repository

Know/DATABASE 2015.05.11 14:15

Mysql을 Yum으로 설치시 아래 문서를 참고하여 Yum Repository를 업데이트한 후 설치.


'Know > DATABASE' 카테고리의 다른 글

MySQL Yum Repository  (0) 2015.05.11
MySql Maximum table size  (0) 2011.03.09
MYSQL Event Scheduler  (0) 2011.02.08
IDENTITY_INSERT  (0) 2009.04.30
SQL 서버 관리자가 알아야 할 11가지 유용한 팁  (0) 2007.07.19
[mssql] 복구 스크립트  (0) 2006.10.20
Trackbacks 0 : Comments 0

IE에서 Websocket 연결시 12057 에러 발생시

Know/Network 2015.05.06 16:21

CRL에 해당 인증서가 폐기목록으로 저장되는 경우 발생

IE의 인터넷옵션 중 고급 > 보안 영역의 "서버의 인증서 해지 확인*" 의 체크를 해제.


'Know > Network' 카테고리의 다른 글

IE에서 Websocket 연결시 12057 에러 발생시  (0) 2015.05.06
route print  (0) 2005.11.08
L4 스위치  (0) 2005.10.25
[펌]TCP/IP  (0) 2005.03.27
Trackbacks 0 : Comments 0

VirtualBox CentOS 게스트 확장 설치

Know/Linux 2015.05.06 16:17

VirtualBox에서 게스트 확장 설치시 아래의 실패 오류가 나는경우.

Building the main Guest Additional module    [실패]

yum install -y gcc kernel-devel

설치 후 reboot

아래의 Developement Tools를 설치 후 Reboot 

yum groupinstall "Development Tools"

그리고 게스트 확장 설치 후 reboot

'Know > Linux' 카테고리의 다른 글

VirtualBox CentOS 게스트 확장 설치  (0) 2015.05.06
/bin/bash^M: bad interpreter: no such file or directory  (0) 2013.02.13
Shell Programing 기초  (0) 2006.07.21
[펌]Linuxdoc Sgml/SMB-HOWTO  (0) 2006.03.12
Redhat 9.0 + Oracle 9.2.0 install  (0) 2005.11.23
MAKEMAP (sendmail)  (0) 2005.11.23
Trackbacks 0 : Comments 0

Netty ChannelGroup

Know/Java 2014.01.22 14:12


A thread-safe Set that contains open Channels and provides various bulk operations on them. Using ChannelGroup, you can categorize Channels into a meaningful group (e.g. on a per-service or per-state basis.) A closed Channel is automatically removed from the collection, so that you don't need to worry about the life cycle of the added Channel. A Channel can belong to more than one ChannelGroup.

ChannelGroup은 쓰레드 세이프하며 Channel을 Set에 관리하며 다양한 오퍼레이션을 제공한다.

ChannelGroup을 사용하면 의미있는 그룹들로 Channel들을 분류할수 있으며 끊긴 Channel들은 자동으로 Collection에서 삭제된다. 하여 추가된 Channel들의 라이프사이클에 관하여 걱정하지 않아도 된다.

하나의 채널은 여러개의 Channel 그룹에 속할수 있다.

'Know > Java' 카테고리의 다른 글

Netty ChannelGroup  (0) 2014.01.22
Selenium을 이용한 UI 테스트  (0) 2013.06.11
JDBC 동작 원리  (0) 2013.02.22
Java Troubleshooting Tool - VisualVM  (0) 2013.02.13
m2 eclipse 버전업시에 에러 ignore  (0) 2012.02.24
Eclipse ERD Plugin  (0) 2011.01.12
Trackbacks 0 : Comments 0

Memcached 내부 동작 원리

Know/Memcached 2013.09.13 07:31


It is important that developers using memcached understand a little bit about how it works internally. While it can be a waste to overfocus on the bits and bytes, as your experience grows understanding the underlying bits become invaluable.

Understanding memory allocation and evictions, and this particular type of LRU is most of what you need to know.

How Memory Gets Allocated For Items

Memory assigned via the -m commandline argument to memcached is reserved for item data storage. The primary storage is broken up (by default) into 1 megabyte pages. Each page is then assigned into slab classes as necessary, then cut into chunks of a specific size for thatslab class.

Once a page is assigned to a class, it is never moved. If your access patterns end up putting 80% of your pages in class 3, there will be less memory available for class 4. The best way to think about this is that memcached is actually many smaller individaul caches. Each class has its own set of statistical counters, and its own LRU.

Classes, sizes, and chunks are shown best by starting up memcached with -vv:

$ ./memcached -vv
class   1: chunk size        80 perslab   13107
class   2: chunk size       104 perslab   10082
class   3: chunk size       136 perslab    7710
class   4: chunk size       176 perslab    5957
class   5: chunk size       224 perslab    4681
class   6: chunk size       280 perslab    3744
class   7: chunk size       352 perslab    2978
class   8: chunk size       440 perslab    2383
class   9: chunk size       552 perslab    1899
class  10: chunk size       696 perslab    1506

In slab class 1, each chunk is 80 bytes, and each page can then contain 13,107 chunks (or items). This continues all the way up to 1 megabyte.

When storing items, they are pushed into the slab class of the nearest fit. If your key + misc data + value is 50 bytes total, it will go into class 1, with an overhead loss of 30 bytes. If your data is 90 bytes total, it will go into class2, with an overhead of 14 bytes.

You can adjust the slab classes with -f and inspect them in various ways, but those're more advanced topics for when you need them. It's best to be aware of the basics because they can bite you.

What Other Memory Is Used

Memcached uses chunks of memory for other functions as well. There is overhead in the hash table it uses to look up your items through. Each connection uses a few small buffers as well. This shouldn't add up to more than a few % extra memory over your specified -m limit, but keep in mind that it's there.

When Memory Is Reclaimed

Memory for an item is not actively reclaimed. If you store an item and it expires, it sits in the LRU cache at its position until it falls to the end and is reused.

However, if you fetch an expired item, memcached will find hte item, notice that it's expired, and free its memory. This gives you the common case of normal cache churn reusing its own memory.

Items can also be evicted to make way for new items that need to be stored, or expired items are discvered and their memory reused.

How Much Memory Will an Item Use

An item will use space for the full length of its key, the internal datastructure for an item, and the length of the data.

You can discover how large an Item is by compiling memcached on your system, then running the "./sizes" utility which is built. On a 32bit system this may look like 32 bytes for items without CAS (server started with -C), and 40 bytes for items with CAS. 64bit systems will be a bit higher due to needing larger pointers. However you gain a lot more flexibility with the ability to put tons of ram into a 64bit box :)

$ ./sizes 
Slab Stats      56
Thread stats    176
Global stats    108
Settings        88
Item (no cas)   32
Item (cas)      40
Libevent thread 96
Connection      320
libevent thread cumulative      
Thread stats cumulative         11376

When Are Items Evicted

Items are evicted if they have not expired (an expiration time of 0 or some time in the future), the slab class is completely out of free chunks, and there are no free pages to assign to a slab class.

How the LRU Decides What to Evict

Memory is also reclaimed when it's time to store a new item. If there are no free chunks, and no free pages in the appropriate slab class, memcached will look at the end of the LRU for an item to "reclaim". It will search the last few items in the tail for one which has already been expired, and is thus free for reuse. If it cannot find an expired item however, it will "evict" one which has not yet expired. This is then noted in several statistical counters.

libevent + Socket Scalability

Memcached uses libevent for scalable sockets, allowing it to easily handle tens of thousands of connections. Each worker thread on memcached runs its own event loop and handles its own clients. They share the cache via some centralized locks, and spread out protocol processing.

This scales very well. Some issues may be seen with extremely high loads (200,00+ operations per second), but if you hit any limits please let us know, as they're usually solvable :)

'Know > Memcached' 카테고리의 다른 글

Memcached 내부 동작 원리  (0) 2013.09.13
Memcached Protocol document  (0) 2013.09.13
Trackbacks 0 : Comments 0

Memcached Protocol document

Know/Memcached 2013.09.13 07:13



Clients of memcached communicate with server through TCP connections.
(A UDP interface is also available; details are below under "UDP
protocol.") A given running memcached server listens on some
(configurable) port; clients connect to that port, send commands to
the server, read responses, and eventually close the connection.

There is no need to send any command to end the session. A client may
just close the connection at any moment it no longer needs it. Note,
however, that clients are encouraged to cache their connections rather
than reopen them every time they need to store or retrieve data.  This
is because memcached is especially designed to work very efficiently
with a very large number (many hundreds, more than a thousand if
necessary) of open connections. Caching connections will eliminate the
overhead associated with establishing a TCP connection (the overhead
of preparing for a new connection on the server side is insignificant
compared to this).

There are two kinds of data sent in the memcache protocol: text lines
and unstructured data.  Text lines are used for commands from clients
and responses from servers. Unstructured data is sent when a client
wants to store or retrieve data. The server will transmit back
unstructured data in exactly the same way it received it, as a byte
stream. The server doesn't care about byte order issues in
unstructured data and isn't aware of them. There are no limitations on
characters that may appear in unstructured data; however, the reader
of such data (either a client or a server) will always know, from a
preceding text line, the exact length of the data block being

Text lines are always terminated by \r\n. Unstructured data is _also_
terminated by \r\n, even though \r, \n or any other 8-bit characters
may also appear inside the data. Therefore, when a client retrieves
data from a server, it must use the length of the data block (which it
will be provided with) to determine where the data block ends, and not
the fact that \r\n follows the end of the data block, even though it


Data stored by memcached is identified with the help of a key. A key
is a text string which should uniquely identify the data for clients
that are interested in storing and retrieving it.  Currently the
length limit of a key is set at 250 characters (of course, normally
clients wouldn't need to use such long keys); the key must not include
control characters or whitespace.


There are three types of commands.

Storage commands (there are six: "set", "add", "replace", "append"
"prepend" and "cas") ask the server to store some data identified by a
key. The client sends a command line, and then a data block; after
that the client expects one line of response, which will indicate
success or failure.

Retrieval commands (there are two: "get" and "gets") ask the server to
retrieve data corresponding to a set of keys (one or more keys in one
request). The client sends a command line, which includes all the
requested keys; after that for each item the server finds it sends to
the client one response line with information about the item, and one
data block with the item's data; this continues until the server
finished with the "END" response line.

All other commands don't involve unstructured data. In all of them,
the client sends one command line, and expects (depending on the
command) either one line of response, or several lines of response
ending with "END" on the last line.

A command line always starts with the name of the command, followed by
parameters (if any) delimited by whitespace. Command names are
lower-case and are case-sensitive.

Expiration times

Some commands involve a client sending some kind of expiration time
(relative to an item or to an operation requested by the client) to
the server. In all such cases, the actual value sent may either be
Unix time (number of seconds since January 1, 1970, as a 32-bit
value), or a number of seconds starting from current time. In the
latter case, this number of seconds may not exceed 60*60*24*30 (number
of seconds in 30 days); if the number sent by a client is larger than
that, the server will consider it to be real Unix time value rather
than an offset from current time.

Error strings

Each command sent by a client may be answered with an error string
from the server. These error strings come in three types:

- "ERROR\r\n"

  means the client sent a nonexistent command name.

- "CLIENT_ERROR <error>\r\n"

  means some sort of client error in the input line, i.e. the input
  doesn't conform to the protocol in some way. <error> is a
  human-readable error string.

- "SERVER_ERROR <error>\r\n"

  means some sort of server error prevents the server from carrying
  out the command. <error> is a human-readable error string. In cases
  of severe server errors, which make it impossible to continue
  serving the client (this shouldn't normally happen), the server will
  close the connection after sending the error line. This is the only
  case in which the server closes a connection to a client.

In the descriptions of individual commands below, these error lines
are not again specifically mentioned, but clients must allow for their

Storage commands

First, the client sends a command line which looks like this:

<command name> <key> <flags> <exptime> <bytes> [noreply]\r\n
cas <key> <flags> <exptime> <bytes> <cas unique> [noreply]\r\n

- <command name> is "set", "add", "replace", "append" or "prepend"

  "set" means "store this data".

  "add" means "store this data, but only if the server *doesn't* already
  hold data for this key".

  "replace" means "store this data, but only if the server *does*
  already hold data for this key".

  "append" means "add this data to an existing key after existing data".

  "prepend" means "add this data to an existing key before existing data".

  The append and prepend commands do not accept flags or exptime.
  They update existing data portions, and ignore new flag and exptime

  "cas" is a check and set operation which means "store this data but
  only if no one else has updated since I last fetched it."

- <key> is the key under which the client asks to store the data

- <flags> is an arbitrary 16-bit unsigned integer (written out in
  decimal) that the server stores along with the data and sends back
  when the item is retrieved. Clients may use this as a bit field to
  store data-specific information; this field is opaque to the server.
  Note that in memcached 1.2.1 and higher, flags may be 32-bits, instead
  of 16, but you might want to restrict yourself to 16 bits for
  compatibility with older versions.

- <exptime> is expiration time. If it's 0, the item never expires
  (although it may be deleted from the cache to make place for other
  items). If it's non-zero (either Unix time or offset in seconds from
  current time), it is guaranteed that clients will not be able to
  retrieve this item after the expiration time arrives (measured by
  server time).

- <bytes> is the number of bytes in the data block to follow, *not*
  including the delimiting \r\n. <bytes> may be zero (in which case
  it's followed by an empty data block).

- <cas unique> is a unique 64-bit value of an existing entry.
  Clients should use the value returned from the "gets" command
  when issuing "cas" updates.

- "noreply" optional parameter instructs the server to not send the
  reply.  NOTE: if the request line is malformed, the server can't
  parse "noreply" option reliably.  In this case it may send the error
  to the client, and not reading it on the client side will break
  things.  Client should construct only valid requests.

After this line, the client sends the data block:

<data block>\r\n

- <data block> is a chunk of arbitrary 8-bit data of length <bytes>
  from the previous line.

After sending the command line and the data blockm the client awaits
the reply, which may be:

- "STORED\r\n", to indicate success.

- "NOT_STORED\r\n" to indicate the data was not stored, but not
because of an error. This normally means that the
condition for an "add" or a "replace" command wasn't met.

- "EXISTS\r\n" to indicate that the item you are trying to store with
a "cas" command has been modified since you last fetched it.

- "NOT_FOUND\r\n" to indicate that the item you are trying to store
with a "cas" command did not exist.

Retrieval command:

The retrieval commands "get" and "gets" operates like this:

get <key>*\r\n
gets <key>*\r\n

- <key>* means one or more key strings separated by whitespace.

After this command, the client expects zero or more items, each of
which is received as a text line followed by a data block. After all
the items have been transmitted, the server sends the string


to indicate the end of response.

Each item sent by the server looks like this:

VALUE <key> <flags> <bytes> [<cas unique>]\r\n
<data block>\r\n

- <key> is the key for the item being sent

- <flags> is the flags value set by the storage command

- <bytes> is the length of the data block to follow, *not* including
  its delimiting \r\n

- <cas unique> is a unique 64-bit integer that uniquely identifies
  this specific item.

- <data block> is the data for this item.

If some of the keys appearing in a retrieval request are not sent back
by the server in the item list this means that the server does not
hold items with such keys (because they were never stored, or stored
but deleted to make space for more items, or expired, or explicitly
deleted by a client).


The command "delete" allows for explicit deletion of items:

delete <key> [noreply]\r\n

- <key> is the key of the item the client wishes the server to delete

- "noreply" optional parameter instructs the server to not send the
  reply.  See the note in Storage commands regarding malformed

The response line to this command can be one of:

- "DELETED\r\n" to indicate success

- "NOT_FOUND\r\n" to indicate that the item with this key was not

See the "flush_all" command below for immediate invalidation
of all existing items.


Commands "incr" and "decr" are used to change data for some item
in-place, incrementing or decrementing it. The data for the item is
treated as decimal representation of a 64-bit unsigned integer.  If
the current data value does not conform to such a representation, the
incr/decr commands return an error (memcached <= 1.2.6 treated the
bogus value as if it were 0, leading to confusing). Also, the item
must already exist for incr/decr to work; these commands won't pretend
that a non-existent key exists with value 0; instead, they will fail.

The client sends the command line:

incr <key> <value> [noreply]\r\n


decr <key> <value> [noreply]\r\n

- <key> is the key of the item the client wishes to change

- <value> is the amount by which the client wants to increase/decrease
the item. It is a decimal representation of a 64-bit unsigned integer.

- "noreply" optional parameter instructs the server to not send the
  reply.  See the note in Storage commands regarding malformed

The response will be one of:

- "NOT_FOUND\r\n" to indicate the item with this value was not found

- <value>\r\n , where <value> is the new value of the item's data,
  after the increment/decrement operation was carried out.

Note that underflow in the "decr" command is caught: if a client tries
to decrease the value below 0, the new value will be 0.  Overflow in
the "incr" command will wrap around the 64 bit mark.

Note also that decrementing a number such that it loses length isn't
guaranteed to decrement its returned length.  The number MAY be
space-padded at the end, but this is purely an implementation
optimization, so you also shouldn't rely on that.


The "touch" command is used to update the expiration time of an existing item
without fetching it.

touch <key> <exptime> [noreply]\r\n

- <key> is the key of the item the client wishes the server to delete

- <exptime> is expiration time. Works the same as with the update commands
  (set/add/etc). This replaces the existing expiration time. If an existing
  item were to expire in 10 seconds, but then was touched with an
  expiration time of "20", the item would then expire in 20 seconds.

- "noreply" optional parameter instructs the server to not send the
  reply.  See the note in Storage commands regarding malformed

The response line to this command can be one of:

- "TOUCHED\r\n" to indicate success

- "NOT_FOUND\r\n" to indicate that the item with this key was not

Slabs Reassign

NOTE: This command is subject to change as of this writing.

The slabs reassign command is used to redistribute memory once a running
instance has hit its limit. It might be desireable to have memory laid out
differently than was automatically assigned after the server started.

slabs reassign <source class> <dest class>\r\n

- <source class> is an id number for the slab class to steal a page from

A source class id of -1 means "pick from any valid class"

- <dest class> is an id number for the slab class to move a page to

The response line could be one of:

- "OK" to indicate the page has been scheduled to move

- "BUSY [message]" to indicate a page is already being processed, try again

- "BADCLASS [message]" a bad class id was specified

- "NOSPARE [message]" source class has no spare pages

- "NOTFULL [message]" dest class must be full to move new pages to it

- "UNSAFE [message]" source class cannot move a page right now

- "SAME [message]" must specify different source/dest ids.

Slabs Automove

NOTE: This command is subject to change as of this writing.

The slabs automove command enables a background thread which decides on its
own when to move memory between slab classes. Its implementation and options
will likely be in flux for several versions. See the wiki/mailing list for
more details.

The automover can be enabled or disabled at runtime with this command.

slabs automove <0|1>

- 0|1|2 is the indicator on whether to enable the slabs automover or not.

The response should always be "OK\r\n"

- <0> means to set the thread on standby

- <1> means to run the builtin slow algorithm to choose pages to move

- <2> is a highly aggressive mode which causes pages to be moved every time
  there is an eviction. It is not recommended to run for very long in this
  mode unless your access patterns are very well understood.


The command "stats" is used to query the server about statistics it
maintains and other internal data. It has two forms. Without


it causes the server to output general-purpose statistics and
settings, documented below.  In the other form it has some arguments:

stats <args>\r\n

Depending on <args>, various internal data is sent by the server. The
kinds of arguments and the data sent are not documented in this version
of the protocol, and are subject to change for the convenience of
memcache developers.

General-purpose statistics

Upon receiving the "stats" command without arguments, the server sents
a number of lines which look like this:

STAT <name> <value>\r\n

The server terminates this list with the line


In each line of statistics, <name> is the name of this statistic, and
<value> is the data.  The following is the list of all names sent in
response to the "stats" command, together with the type of the value
sent for this name, and the meaning of the value.

In the type column below, "32u" means a 32-bit unsigned integer, "64u"
means a 64-bit unsigned integer. '32u.32u' means two 32-bit unsigned
integers separated by a colon (treat this as a floating point number).

| Name                  | Type    | Meaning                                   |
| pid                   | 32u     | Process id of this server process         |
| uptime                | 32u     | Number of secs since the server started   |
| time                  | 32u     | current UNIX time according to the server |
| version               | string  | Version string of this server             |
| pointer_size          | 32      | Default size of pointers on the host OS   |
|                       |         | (generally 32 or 64)                      |
| rusage_user           | 32u.32u | Accumulated user time for this process    |
|                       |         | (seconds:microseconds)                    |
| rusage_system         | 32u.32u | Accumulated system time for this process  |
|                       |         | (seconds:microseconds)                    |
| curr_items            | 32u     | Current number of items stored            |
| total_items           | 32u     | Total number of items stored since        |
|                       |         | the server started                        |
| bytes                 | 64u     | Current number of bytes used              |
|                       |         | to store items                            |
| curr_connections      | 32u     | Number of open connections                |
| total_connections     | 32u     | Total number of connections opened since  |
|                       |         | the server started running                |
| connection_structures | 32u     | Number of connection structures allocated |
|                       |         | by the server                             |
| reserved_fds          | 32u     | Number of misc fds used internally        |
| cmd_get               | 64u     | Cumulative number of retrieval reqs       |
| cmd_set               | 64u     | Cumulative number of storage reqs         |
| cmd_flush             | 64u     | Cumulative number of flush reqs           |
| cmd_touch             | 64u     | Cumulative number of touch reqs           |
| get_hits              | 64u     | Number of keys that have been requested   |
|                       |         | and found present                         |
| get_misses            | 64u     | Number of items that have been requested  |
|                       |         | and not found                             |
| delete_misses         | 64u     | Number of deletions reqs for missing keys |
| delete_hits           | 64u     | Number of deletion reqs resulting in      |
|                       |         | an item being removed.                    |
| incr_misses           | 64u     | Number of incr reqs against missing keys. |
| incr_hits             | 64u     | Number of successful incr reqs.           |
| decr_misses           | 64u     | Number of decr reqs against missing keys. |
| decr_hits             | 64u     | Number of successful decr reqs.           |
| cas_misses            | 64u     | Number of CAS reqs against missing keys.  |
| cas_hits              | 64u     | Number of successful CAS reqs.            |
| cas_badval            | 64u     | Number of CAS reqs for which a key was    |
|                       |         | found, but the CAS value did not match.   |
| touch_hits            | 64u     | Numer of keys that have been touched with |
|                       |         | a new expiration time                     |
| touch_misses          | 64u     | Numer of items that have been touched and |
|                       |         | not found                                 |
| auth_cmds             | 64u     | Number of authentication commands         |
|                       |         | handled, success or failure.              |
| auth_errors           | 64u     | Number of failed authentications.         |
| evictions             | 64u     | Number of valid items removed from cache  |
|                       |         | to free memory for new items              |
| reclaimed             | 64u     | Number of times an entry was stored using |
|                       |         | memory from an expired entry              |
| bytes_read            | 64u     | Total number of bytes read by this server |
|                       |         | from network                              |
| bytes_written         | 64u     | Total number of bytes sent by this server |
|                       |         | to network                                |
| limit_maxbytes        | 32u     | Number of bytes this server is allowed to |
|                       |         | use for storage.                          |
| threads               | 32u     | Number of worker threads requested.       |
|                       |         | (see doc/threads.txt)                     |
| conn_yields           | 64u     | Number of times any connection yielded to |
|                       |         | another due to hitting the -R limit.      |
| hash_power_level      | 32u     | Current size multiplier for hash table    |
| hash_bytes            | 64u     | Bytes currently used by hash tables       |
| hash_is_expanding     | bool    | Indicates if the hash table is being      |
|                       |         | grown to a new size                       |
| expired_unfetched     | 64u     | Items pulled from LRU that were never     |
|                       |         | touched by get/incr/append/etc before     |
|                       |         | expiring                                  |
| evicted_unfetched     | 64u     | Items evicted from LRU that were never    |
|                       |         | touched by get/incr/append/etc.           |
| slab_reassign_running | bool    | If a slab page is being moved             |
| slabs_moved           | 64u     | Total slab pages moved                    |

Settings statistics
CAVEAT: This section describes statistics which are subject to change in the

The "stats" command with the argument of "settings" returns details of
the settings of the running memcached.  This is primarily made up of
the results of processing commandline options.

Note that these are not guaranteed to return in any specific order and
this list may not be exhaustive.  Otherwise, this returns like any
other stats command.

| Name              | Type     | Meaning                                      |
| maxbytes          | size_t   | Maximum number of bytes allows in this cache |
| maxconns          | 32       | Maximum number of clients allowed.           |
| tcpport           | 32       | TCP listen port.                             |
| udpport           | 32       | UDP listen port.                             |
| inter             | string   | Listen interface.                            |
| verbosity         | 32       | 0 = none, 1 = some, 2 = lots                 |
| oldest            | 32u      | Age of the oldest honored object.            |
| evictions         | on/off   | When off, LRU evictions are disabled.        |
| domain_socket     | string   | Path to the domain socket (if any).          |
| umask             | 32 (oct) | umask for the creation of the domain socket. |
| growth_factor     | float    | Chunk size growth factor.                    |
| chunk_size        | 32       | Minimum space allocated for key+value+flags. |
| num_threads       | 32       | Number of threads (including dispatch).      |
| stat_key_prefix   | char     | Stats prefix separator character.            |
| detail_enabled    | bool     | If yes, stats detail is enabled.             |
| reqs_per_event    | 32       | Max num IO ops processed within an event.    |
| cas_enabled       | bool     | When no, CAS is not enabled for this server. |
| tcp_backlog       | 32       | TCP listen backlog.                          |
| auth_enabled_sasl | yes/no   | SASL auth requested and enabled.             |
| item_size_max     | size_t   | maximum item size                            |
| maxconns_fast     | bool     | If fast disconnects are enabled              |
| hashpower_init    | 32       | Starting size multiplier for hash table      |
| slab_reassign     | bool     | Whether slab page reassignment is allowed    |
| slab_automove     | bool     | Whether slab page automover is enabled       |

Item statistics
CAVEAT: This section describes statistics which are subject to change in the

The "stats" command with the argument of "items" returns information about
item storage per slab class. The data is returned in the format:

STAT items:<slabclass>:<stat> <value>\r\n

The server terminates this list with the line


The slabclass aligns with class ids used by the "stats slabs" command. Where
"stats slabs" describes size and memory usage, "stats items" shows higher
level information.

The following item values are defined as of writing.

Name                   Meaning
number                 Number of items presently stored in this class. Expired
                       items are not automatically excluded.
age                    Age of the oldest item in the LRU.
evicted                Number of times an item had to be evicted from the LRU
                       before it expired.
evicted_nonzero        Number of times an item which had an explicit expire
                       time set had to be evicted from the LRU before it
evicted_time           Seconds since the last access for the most recent item
                       evicted from this class. Use this to judge how
                       recently active your evicted data is.
outofmemory            Number of times the underlying slab class was unable to
                       store a new item. This means you are running with -M or
                       an eviction failed.
tailrepairs            Number of times we self-healed a slab with a refcount
                       leak. If this counter is increasing a lot, please
                       report your situation to the developers.
reclaimed              Number of times an entry was stored using memory from
                       an expired entry.
expired_unfetched      Number of expired items reclaimed from the LRU which
                       were never touched after being set.
evicted_unfetched      Number of valid items evicted from the LRU which were
                       never touched after being set.

Note this will only display information about slabs which exist, so an empty
cache will return an empty set.

Item size statistics
CAVEAT: This section describes statistics which are subject to change in the

The "stats" command with the argument of "sizes" returns information about the
general size and count of all items stored in the cache.
WARNING: This command WILL lock up your cache! It iterates over *every item*
and examines the size. While the operation is fast, if you have many items
you could prevent memcached from serving requests for several seconds.

The data is returned in the following format:

<size> <count>\r\n

The server terminates this list with the line


'size' is an approximate size of the item, within 32 bytes.
'count' is the amount of items that exist within that 32-byte range.

This is essentially a display of all of your items if there was a slab class
for every 32 bytes. You can use this to determine if adjusting the slab growth
factor would save memory overhead. For example: generating more classes in the
lower range could allow items to fit more snugly into their slab classes, if
most of your items are less than 200 bytes in size.

Slab statistics
CAVEAT: This section describes statistics which are subject to change in the

The "stats" command with the argument of "slabs" returns information about
each of the slabs created by memcached during runtime. This includes per-slab
information along with some totals. The data is returned in the format:

STAT <slabclass>:<stat> <value>\r\n
STAT <stat> <value>\r\n

The server terminates this list with the line


| Name            | Meaning                                                  |
| chunk_size      | The amount of space each chunk uses. One item will use   |
|                 | one chunk of the appropriate size.                       |
| chunks_per_page | How many chunks exist within one page. A page by         |
|                 | default is less than or equal to one megabyte in size.   |
|                 | Slabs are allocated by page, then broken into chunks.    |
| total_pages     | Total number of pages allocated to the slab class.       |
| total_chunks    | Total number of chunks allocated to the slab class.      |
| get_hits        | Total number of get requests serviced by this class.     |
| cmd_set         | Total number of set requests storing data in this class. |
| delete_hits     | Total number of successful deletes from this class.      |
| incr_hits       | Total number of incrs modifying this class.              |
| decr_hits       | Total number of decrs modifying this class.              |
| cas_hits        | Total number of CAS commands modifying this class.       |
| cas_badval      | Total number of CAS commands that failed to modify a     |
|                 | value due to a bad CAS id.                               |
| touch_hits      | Total number of touches serviced by this class.          |
| used_chunks     | How many chunks have been allocated to items.            |
| free_chunks     | Chunks not yet allocated to items, or freed via delete.  |
| free_chunks_end | Number of free chunks at the end of the last allocated   |
|                 | page.                                                    |
| mem_requested   | Number of bytes requested to be stored in this slab[*].  |
| active_slabs    | Total number of slab classes allocated.                  |
| total_malloced  | Total amount of memory allocated to slab pages.          |

* Items are stored in a slab that is the same size or larger than the
  item.  mem_requested shows the size of all items within a
  slab. (total_chunks * chunk_size) - mem_requested shows memory
  wasted in a slab class.  If you see a lot of waste, consider tuning
  the slab factor.

Other commands

"flush_all" is a command with an optional numeric argument. It always
succeeds, and the server sends "OK\r\n" in response (unless "noreply"
is given as the last parameter). Its effect is to invalidate all
existing items immediately (by default) or after the expiration
specified.  After invalidation none of the items will be returned in
response to a retrieval command (unless it's stored again under the
same key *after* flush_all has invalidated the items). flush_all
doesn't actually free all the memory taken up by existing items; that
will happen gradually as new items are stored. The most precise
definition of what flush_all does is the following: it causes all
items whose update time is earlier than the time at which flush_all
was set to be executed to be ignored for retrieval purposes.

The intent of flush_all with a delay, was that in a setting where you
have a pool of memcached servers, and you need to flush all content,
you have the option of not resetting all memcached servers at the
same time (which could e.g. cause a spike in database load with all
clients suddenly needing to recreate content that would otherwise
have been found in the memcached daemon).

The delay option allows you to have them reset in e.g. 10 second
intervals (by passing 0 to the first, 10 to the second, 20 to the
third, etc. etc.).

"version" is a command with no arguments:


In response, the server sends

"VERSION <version>\r\n", where <version> is the version string for the

"verbosity" is a command with a numeric argument. It always succeeds,
and the server sends "OK\r\n" in response (unless "noreply" is given
as the last parameter). Its effect is to set the verbosity level of
the logging output.

"quit" is a command with no arguments:


Upon receiving this command, the server closes the
connection. However, the client may also simply close the connection
when it no longer needs it, without issuing this command.

UDP protocol

For very large installations where the number of clients is high enough
that the number of TCP connections causes scaling difficulties, there is
also a UDP-based interface. The UDP interface does not provide guaranteed
delivery, so should only be used for operations that aren't required to
succeed; typically it is used for "get" requests where a missing or
incomplete response can simply be treated as a cache miss.

Each UDP datagram contains a simple frame header, followed by data in the
same format as the TCP protocol described above. In the current
implementation, requests must be contained in a single UDP datagram, but
responses may span several datagrams. (The only common requests that would
span multiple datagrams are huge multi-key "get" requests and "set"
requests, both of which are more suitable to TCP transport for reliability
reasons anyway.)

The frame header is 8 bytes long, as follows (all values are 16-bit integers
in network byte order, high byte first):

0-1 Request ID
2-3 Sequence number
4-5 Total number of datagrams in this message
6-7 Reserved for future use; must be 0

The request ID is supplied by the client. Typically it will be a
monotonically increasing value starting from a random seed, but the client
is free to use whatever request IDs it likes. The server's response will
contain the same ID as the incoming request. The client uses the request ID
to differentiate between responses to outstanding requests if there are
several pending from the same server; any datagrams with an unknown request
ID are probably delayed responses to an earlier request and should be

The sequence number ranges from 0 to n-1, where n is the total number of
datagrams in the message. The client should concatenate the payloads of the
datagrams for a given response in sequence number order; the resulting byte
stream will contain a complete response in the same format as the TCP
protocol (including terminating \r\n sequences).

'Know > Memcached' 카테고리의 다른 글

Memcached 내부 동작 원리  (0) 2013.09.13
Memcached Protocol document  (0) 2013.09.13
Trackbacks 0 : Comments 0

Selenium을 이용한 UI 테스트

Know/Java 2013.06.11 17:29

Selenium을 이용한 UI 테스트

1. Selenium 개요

1.1 Selenium이란

  • Selenium은 웹 어플리케이션을 위한 테스팅 프레임워크로 자동화 테스트를 위한 여러가지 강력한 기능을 지원해준다.
  • 다양한 브라우저들을 지원하며, 다양한 테스트 작성 언어(Java, Ruby, Groovy, Python, PHP, and Perl.)를 지원한다.
  • 현재 WebDriver라는 웹 자동화 툴과 통합하는 작업이 진행되고 있다. (2.0ax 버전)
  • 홈페이지 : http://seleniumhq.org/http://code.google.com/p/selenium/

1.2 Selenium Components

1.2.1 Selenium IDE
  • Selenium Test Case를 만들고 실행하기 위한 통합 개발 환경
  • 파이어폭스 확장 플러그인으로 제공되며, Selenium Test Case를 쉽게 작성할 수 있도록 도와준다
  • 레코딩이 쉽고, 재생을 지원한다.
  • 브라우저 내의 사용자의 행동을 저장하여 다양한 언어(C#, Java, Perl, PHP, Python, Ruby 등)로 변환 가능 하다.
  • 참고 : http://seleniumhq.org/projects/ide/
1.2.2 Selenium Core
  • Selenium의 Core 라이브러리
1.2.3 Selenium RC(Remote Control)
  • http 를 통해 command 를 받는 Java 로 작성된 서버
  • Selenium API로 작성한 테스트 코드를 실행시켜 주는 역할을 한다.
  • 테스트용 PC 에 설치를 한 후 원격지에서 unit 테스트 framework로 웹어플리케이션의 자동화 테스트를 가능하게 한다.
  • 참고 : http://seleniumhq.org/projects/remote-control/
1.2.4 Selenium GRID
  • Selenium GRID를 이용해 테스트 코드를 여러대의 Selenium RC에서 동시에 실행 할 수 있다.
  • 테스트 수행속도를 향상시키기 위해 분산해서 처리하거나 여러가지 환경에서 테스트가 필요할 때 사용한다.
  • 서로다른 브라우저 환경에서 일관성있는 테스트가 가능하다.
  • 참고 : http://selenium-grid.seleniumhq.org/how_it_works.html

2. Selenium IDE의 사용

2.1 Selenium IDE 설치

2.1.1 다운로드 및 설치
2.1.2 설치 확인
  • "Fire Fox > 도구" 메뉴 에서 설치 확인
2.1.3 Selenium IDE Toolbar
  • 1. Speed Control : 테스트 케이스의 속도 재생 속도 조절
  • 2, Run All : Test Suite를 재생
  • 3. Run : Test Case를 재생
  • 4. Pause/Resume : 테스트 케이스의 정지와 리스타트
  • 5. Step : 클릭 시 한번에 한 라인씩 수행
  • 6. TestRunner Mode : 브라우저 내에서 테스트 실행 및 결과를 HTML Table 형식으로 볼 수 있음 (Firefox 3.6에서 잘 안 됨)
  • 8. Record : 유저 브라우저의 액션을 레코딩 시작/정지 버튼

2.2 Selenium IDE 테스팅 예제

  • Selenium IDE에서 Recording 후 저장된 테스트코드를 수행하면 된다.
2.2.1 Recording
  • ① Firefox를 열어서 도구 => Selenium IDE를 선택해서 IDE를 활성화 시킨다
  • ② Test하기 원하는 사이트로 이동 한다. 또는 Base URL 입럭
  • ③ 빨강색 Record버튼을 누른다.
  • ④ Firefox창에서 원하는 액션을 수행하면 해당내용이 자동으로 저장된다.
  • ⑤ 원하는 테스트가 끝났으면 다시 빨강색 Record버튼을 눌러서 종료시킨다.
2.2.2 저장된 테스트코드 수행
  • ① 테스트 수행속도를 설정한다.
  • ② Play 버튼을 눌러서 테스트를 수행한다.
2.2.3 테스트를 자바코드로 전환
  • Selenium IDE에서 테스트 작성 후 IDE 메뉴에서 Options => Format 으로 원하는 언어를 선택하면 된다.
  • 아래는 JUnit4 기반의 테스트 코드 예제이다.
  • 테스트 코드의 "Untitled" 와 "change-this-to-the-site-you-are-testing"를 수정하면 된다.
    package com.example.tests;
    import com.thoughtworks.selenium.*;
    import java.util.regex.Pattern;
    public class Untitled extends SeleneseTestCase {
    	public void setUp() throws Exception {
    		setUp("http://change-this-to-the-site-you-are-testing/", "*chrome");
    	public void testUntitled() throws Exception {
    		selenium.type("query", "리쌍");
2.2.4 간단 데모

3. Selenium RC의 사용

3.1 다운로드 및 설치

3.1 Selenium RC 예제

3.1.1 Selenium RC 서버 Start
  • java -jar selenium-remote-control-1.0.3\selenium-server-1.0.3\selenium-server.jar
3.1.2 JUnit 테스트
  • 아래는 Selenium IDE로 저장한 자바코드를 Selenium RC를 이용해 테스트하는 예제이다.
    import com.thoughtworks.selenium.SeleneseTestCase;
    public class SimpleRCTest extends SeleneseTestCase {
        public void setUp() throws Exception {
            setUp("http://dev.music.naver.com/", "*firefox");
        public void testSearch() throws Exception {
            selenium.type("query", "리쌍");
  • Selenium관련 maven 빌드 설정
    -- repository 설정
    -- dependency 설정
    -- 아래서  WebDriver 간단설명 예정으로 WebDriver 포함 버전으로 설정했음.
3.1.3 간단 데모

4. WebDriver를 이용한 UI 테스트

4.1 WebDriver 개요

4.1.1 WebDriver란?
  • 단순한 API들로 구성된 개발자 중심의 웹 UI 테스트 자동화 도구 이다.
  • 다양한 브라우저(FireFox, Internet Explorer, Safari, Chrome...)에서 일관성 있는 테스트를 할 수 있다.
  • Selenium 1.0에서 지원하지 못하던 테스트 기능 문제를 개선하였다.
  • multiple frames, multiple browser windows, popups, and alerts, Page navigation, Drag-and-drop, AJAX-based UI elements등 테스트 가능하다
  • 현재 Selenium과 통합되어 2.0a 버전이 개발되고 있다.
4.1.2 WebDriver 장점
  • Driver 변경만으로 다양한 환경에서 테스트 수행이 가능 하다.
  • 표준 API 지원을 통해 개발자 UI 테스트에 최적화 되어 있다.
  • Real browser 외에도 HtmlUnitDriver 지원을 통한 빠른 테스트 피드백이 가능 하다.
  • 현재 Selenium과 연계를 통해 장단점 상호 보완 중이다.
4.1.3 WebDriver 단점
  • 개발자 중심의 UI 테스트 도구인 관계로 초기 학습 시간 및 비용에 대한 부담이 발생한다.
  • 시나리오에 기인한 테스트케이스의 작성이 까다롭고 불명확할 수 있다.

4.2 WebDriver 예제

4.2.1 간단 예제
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.htmlunit.HtmlUnitDriver;

public class Example  {
    public static void main(String[] args) {
        // Create a new instance of the html unit driver
        // Notice that the remainder of the code relies on the interface,
        // not the implementation.
        WebDriver driver = new HtmlUnitDriver();

        // And now use this to visit Google

        // Find the text input element by its name
        WebElement element = driver.findElement(By.name("q"));

        // Enter something to search for

        // Now submit the form. WebDriver will find the form for us from the element

        // Check the title of the page
        System.out.println("Page title is: " + driver.getTitle());


'Know > Java' 카테고리의 다른 글

Netty ChannelGroup  (0) 2014.01.22
Selenium을 이용한 UI 테스트  (0) 2013.06.11
JDBC 동작 원리  (0) 2013.02.22
Java Troubleshooting Tool - VisualVM  (0) 2013.02.13
m2 eclipse 버전업시에 에러 ignore  (0) 2012.02.24
Eclipse ERD Plugin  (0) 2011.01.12
Trackbacks 0 : Comments 0

JDBC 동작 원리

Know/Java 2013.02.22 09:31


Mysql Statement Cancellation tiemr 관련 에러를 찾아보다가 찾게 된글


JDBC 동작 원리에 대해 자세히 설명이 되어있다.


한번쯤 읽어보면 도움이 될듯한 글


원본글 http://helloworld.naver.com/helloworld/1321



NHN Business Platform 웹플랫폼개발랩 강운덕

성능 문제나 장애가 발생할 때 중요하게 살펴보는 부분(tier)은 WAS(Web Application Server)와 DBMS입니다. 대부분의 경우에 WAS를 담당하는 조직과 DBMS를 담당하는 조직이 달라, 각자 담당 분야를 중심으로 상황을 파악하려 합니다. 이때 상대적으로 관심을 못 받는 사각지대가 생기는데, 바로 WAS와 DBMS 사이입니다. Java 애플리케이션을 기준으로 말하면 DBCP와 JDBC입니다. 이 글에서는 JDBC의 타임아웃 설정을 중심으로 장애에 대응하는 방법을 설명하겠습니다.

  • 어느 날 DDoS 공격, 그 뒤로 먹통이 된 WAS

    다음과 같은 사고가 일어났다고 가정해 보자.

    DDoS 공격으로 서비스 전체가 정상적으로 동작하지 않았다. L4가 정상으로 동작하지 않아 네트워크가 단절되었고, 이로 인해 WAS도 동작 불능 상태에 빠졌다. 이후 보안팀에서는 DDoS 공격을 전부 차단했고, 네트워크도 정상으로 복구되었다. 그러나 WAS는 여전히 동작 불능 상태이다.

    서비스팀에서는 WAS의 ThreadDump를 통해 JDBC의 API 호출 중에 WAS가 정지해 있음을 확인했다. 10분이 지나고 20분이 지나도 WAS는 여전히 정지 상태(WAITING)였고, 서비스는 정상으로 동작하지 않았다. 그런데 30분이 지날 무렵 갑자기 Exception을 발생시키면서 서비스가 복구되었다.

    QueryTimeout 값도 3초로 설정되어 있는데 왜 30분씩이나 WAS가 정지 상태에 있었으며, 30분이 지나니 왜 정상적으로 WAS가 동작했던 것일까?

    정답은 JDBC의 타임아웃 과정을 이해하면 알 수 있다.

  • 왜 JDBC 드라이버에 대해서 알아야 하는가?

    JDBC는 DBMS에 접근하기 위한 표준 API이다. Sun은 4가지 타입의 드라이브를 정의하는데, NHN에서 주로 사용하는 것은 Type4 형식이다. JDBC Type4 드라이버는 Java로만 작성되어 있으며(pure java), Java 애플리케이션에서 소켓을 이용해 DBMS와 통신한다.


    그림 1 JDBC Type4 드라이버의 DBMS 통신 구조

    Type4 드라이버는 소켓을 통해 바이트 스트림(byte stream)을 처리하기 때문에 HttpClient 같은 네트워크 라이브러리와 근본적으로 동작이 같다. 즉, 많은 CPU자원을 소모하고, ResponseTime의 손해가 있으며, 다른 네트워크 라이브러리가 가지고 있는 장애 포인트를 동일하게 가지고 있다. HttpClient를 사용한 경험이 있다면 타임아웃 값을 제대로 설정하지 않아 장애(hang)가 발생한 상황을 겪어 보았을 것이다. Type4 드라이버 역시 SocketTimeout 값을 제대로 설정하지 않으면 동일한 장애가 발생할 수 있다.

    JDBC 드라이버의 SocketTimeout 값을 어떻게 설정하면 좋을지, 그리고 무엇을 고려해야 히는지 알아보자.

  • WAS와 DBMS의 통신 시 타임아웃 계층

    그림 2는 WAS와 DBMS와 통신 시 타임아웃 계층을 단순화한 것이다.


    그림 2 타임아웃 계층

    상위 레벨의 타임아웃은 하위 레벨의 타임아웃에 의존성을 가지고 있다. 하위 레벨의 타임아웃이 정상으로 동작해야 상위 레벨의 타임아웃도 정상으로 동작한다. 예를 들어, JDBC Driver SocketTimeout이 정상으로 동작하지 않으면, 그보다 상위 레벨의 타임아웃인 StatementTimeout과 TransactionTimeout도 정상으로 동작하지 않는다.

    "StatementTimeout을 설정했는데도 네트워크 장애가 발생했을 때, StatementTimeout이 동작하지 않아 애플리케이션이 장애 상황에서 회복되지 않았어요"란 문의를 많이 받았다. StatementTimeout은 네트워크 연결 장애에 대한 타임아웃을 담당하는 것이 아니다. StatementTimeout은 Statement 한 개의 수행 시간을 제한하는 기능만 담당한다. 네트워크 장애에 대비하는 타임아웃은 JDBC Driver SoecketTimeout이 처리해야 한다.

    JDBC Driver SocketTimeout은 OS의 SocketTimeout 설정에 영향을 받는다. JDBC Driver SocketTimeout을 설정하지 않아도 네트워크 장애 발생 이후 30분이 지나면 JDBC Connection Hang이 복구되는 것은 OS의 SocketTimeout 설정때문이다.

    그림 2에서 DBCP Connection Pool이 타임아웃 계층과 분리되어 왼쪽에 있는 것을 볼 수 있다. DBCP는 Connection을 생성하고 관리하는 일을 하며, 타임아웃 처리에는 관여하지 않는다. DBCP 내부에서 Connection을 생성하거나 Connection 유효성을 확인하려 Validation Query를 보낼 때에는 SocketTimeout이 영향을 주지만 애플리케이션에 직접적인 영향을 주지는 않는다.

    단, 애플리케이션 로직에서 DBCP에 getConnection() 메서드를 호출할 때 Connection을 애플리케이션이 얻을 때까지의 타임아웃을 지정할 수 있다. 하지만 이것은 JDBC의 ConnectTimeout과는 무관하다.


    그림 3 각 레벨 별 타임아웃

  • TransactionTimeout이란?

    TransactionTimeout은 프레임워크(Spring, EJB Container)나 애플리케이션 레벨에서 유효한 타임아웃이다.

    TransactionTimeout은 생소한 개념일 수 있다. 간단히 설명하면 "StatementTimeout x N(Statement 수행 수) + α(가비지 컬렉션 및 기타)"라고 할 수 있다. 전체 Statement 수행 시간을 허용할 수 있는 최대 시간 이내로 제한하려 할 때 TransactionTimeout을 사용한다.

    가령 Statement 한 개를 수행할 때 0.1초가 필요하다면, 몇 개 안 되는 Statement를 수행할 때에는 문제가 없다. 그러나 Statement 10만 개를 수행할 때에는 일만 초(약 7시간)가 필요하다. TransactionTimeout은 이런 경우에 사용할 수 있다.

    실 구현체로 EJB CMT(Container Managed Transaction)가 가장 대표적인 예이다. EJB CMT는 제작사마다 구현 방식과 동작 과정이 다르다. NHN에서는 EJB Container를 사용하지 않으므로, 가장 익숙한 예는 Spring의 TransactionTimeout이 될 수 있겠다. Spring에서는 다음과 같이 XML을 이용하여 설정하거나, Java 코드에서 @Transactional을 이용하여 타임아웃을 설정할 수 있다.

    <tx:method name="…" timeout="3">

    Spring에서 제공하는 TransactionTimeout은 매우 단순하다. 해당 Transaction의 시작 시간과 경과 시간을 기록하면서, 특정 이벤트 발생 시 경과 시간을 확인하여 타임아웃 이상일 경우 예외(Exception)를 발생하도록 하고 있다.

    Spring에는 Transaction Synchronization방식이라고 하여 Connection을 ThreadLocal에저장해 두고 사용한다. ThreadLocal에 Connection 저장 시 Transaction의 시작 시간과 타임아웃 시간을 같이 기록하고, Proxy Connection을 사용하여 Statement를 생성하는 작업을 시도할 경우 경과 시간을 체크하여 예외를 발생시키도록 구현되어있다.

    EJB CMT 구현 방식 또한 크게 다르지 않다. 만약 TransactionTimeout이 매우 중요하고 사용하는 컨테이너나 프레임워크에서 이런 기능을 제공하지 않는다면 직접 구현해서 사용해도 별 무리가 없을 정도로 매우 단순한 구조이다. TransactionTimeout에 대한 표준 API는 없다.

    수행 시간이 200ms인 Statement가 5개 이하이고 기타 부수적인 비즈니스 로직 처리 시간이나 프레임워크 동작 시간이 100ms일 경우, TrasactionTimeout시간은 1100ms((200 x 5)+100) 이상으로 설정해야 한다.

  • StatementTimeout 이란?

    Statement 하나가 얼마나 오래 수행되어도 괜찮은지에 대한 한계 값이다. JDBC API인 Statement에 타임아웃 값을 설정하며, 이 값을 바탕으로 JDBC 드라이버가 StatementTimeout을 처리한다. JDBC API인 java.sql.Statement.setQueryTimeout(int timeout) 메서드로 설정한다.

    요즘 개발 환경에서는 개발자가 직접 StatementTimeout을 Java 코드로 설정하는 경우는 드물며, 프레임워크를 이용하여 해결하는 경우가 많다. iBatis를 예로 들어 설명하자면 "sql-map-config.xml" 파일의 sqlMapConfig/settings에 @defaultStatementTimeout 값으로 기본값을 설정할 수 있다. 또한 "sql-map.xml" 파일의 statement, select, insert, update 구문마다 @timeout 값으로 개별적으로 설정할 수 있다.

    StatementTimeout 시간은 애플리케이션 특성에 따라 지정하기 때문에 이에 대한 설정 권장 값은 없다.

  • JDBC 드라이버의 StatementTimeout 동작 방식

    StatementTimeout의 동작방식은 DBMS나 드라이버별로 다르다.

    Oracle과 Microsoft SQL Server의 동작 방식이 서로 비슷하고, MySQL과 CUBRID의 동작 방식이 서로 비슷하다.

  • Oracle JDBC Statement의 QueryTimeout


    그림 4 Oracle JDBC Statement의 QueryTimeout 동작 과정

    Oracle JDBC Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

  • Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.
  • Statement.executeQuery() 메서드를 호출한다.
  • Statement는 자신의 Connection을 사용하여 Oracle DBMS로 쿼리를 전송한다.
  • Statement는 타임아웃 처리를 위해 OracleTimeoutPollingThread(classloader별로 1개 존재)에 Statement를 등록한다.
  • 타임아웃이 발생한다.
  • OracleTimeoutPollingThread는 OracleStatement.cancel() 메서드를 호출한다.
  • Connection을 통해 취소(cancel) 메시지를 전송하여 수행중인 쿼리를 취소한다
  • jTDS(Microsoft SQL Server) Statement의 QueryTimeout


    그림 5 jTDS(Micsofot SQL Server) Statement의 QueryTimeout의 동작 과정

    jTDS(Microsoft SQL Server) Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

  • Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.
  • Statement.executeQuery() 메서드를 호출한다.
  • Statement는 내부 Connection을 사용하여 Microsoft SQL DBMS로 쿼리를 전송한다.
  • Statement는 타임아웃 처리를 위해 TimerThread에 Statement를 등록한다.
  • 타임아웃이 발생한다.
  • TimerThread는 JtdsStatement 객체 내부의 TdsCore.cancel() 메서드를 호출한다.
  • ConnectionJDBC을 통해 취소 메시지를 전송하여 수행중인 쿼리를 취소한다.
  • MySQL JDBC Statement의 QueryTimeout(5.0.8 버전)


    그림 6 MySQL JDBC Statement의 QueryTimeout의 동작 과정(5.0.8 버전)

    MySQL JDBC Statement(5.0.8 버전)의 QueryTimeout은 다음과 같은 과정으로 동작한다.

  • Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.
  • Statement.executeQuery() 메서드를 호출한다.
  • Statement는 내부 Connection을 사용하여 MySQL DBMS로 쿼리를 전송한다.
  • Statement는 타임아웃 처리를 위해 새로운 타임아웃 처리용 스레드를 생성한다. 5.1.x 버전에서는 Connection에 한 개의 스레드가 할당되는 것으로 변경되었다.
  • 스레드에 타임아웃 처리를 등록한다.
  • 타임아웃이 발생한다.
  • 타임아웃 처리 스레드가 Statement와 동일한 설정의 Connection을 생성한다.
  • 생성된 Connection을 사용하여 취소 쿼리(KILL QUERY "connectionId")를 전송한다.
  • CUBRID JDBC Statement의 QueryTimeout


    그림 7 CUBRID JDBC Statement의 QueryTimeout의 동작 과정

    CUBRID JDBC Statement의 QueryTimeout은 다음과 같은 과정으로 동작한다.

  • Connection.createStatement() 메서드를 호출하여 Statement를 생성한다.
  • Statement.executeQuery() 메서드를 호출한다.
  • Statement는 내부 Connection을 사용하여 CUBRID DBMS로 쿼리를 전송한다.
  • Statement는 타임아웃 처리를 위해 새로운 타임아웃용 스레드를 생성한다.
  • 스레드에 타임아웃 처리를 등록한다.
  • 타임아웃이 발생한다.
  • 타임아웃 처리 스레드가 Statement와 동일한 설정의 Connection을 생성한다.
  • 생성된 Connection을 사용하여 취소 메시지를 전송한다.
  • JDBC 드라이버의 SocketTimeout 이란?

    JDBC Driver Type4는 소켓을 사용하여 DBMS에 연결하는 방식이고, 애플리케이션과 DBMS 사이의 ConnectTimeout 처리는 DBMS에서 하지 않는다.

    JDBC 드라이버의 SocketTimeout 값은 DBMS가 비정상으로 종료되었거나 네트워크 장애(기기 장애 등)가 발생했을 때 필요한 값이다. TCP/IP의 구조상 소켓에는 네트워크의 장애를 감지할 수 있는 방법이 없다. 그렇기 때문에 애플리케이션은 DBMS와의 연결 끊김을 알 수 없다. 이럴 때 SocketTimeout이 설정되어 있지 않다면 애플리케이션은 DBMS로부터의 결과를 무한정 기다릴 수도 있다(이러한 Connection을 Dead Connection이라고 부르기도 한다).

    이러한 상태를 방지하기 위해 소켓에 타임아웃을 설정해야 한다. SocketTimeout은 JDBC 드라이버에서 설정할 수 있다. SocketTimeout을 설정하면 네트워크 장애 발생 시 무한 대기 상황을 방지하여 장애 시간을 단축할 수 있다.

    단, SocketTimeout 값을 Statement의 수행 시간 제한을 위해 사용하는 것은 바람직하지 않다. 그러므로 SocketTimeout 값은 StatementTimeout 값보다는 크게 설정해야 한다. SocketTimeout값이 StatementTimeout보다 작으면, SocketTimeout이 먼저 동작하므로 StatementTimeout 값은 의미가 없게 되어 동작하지 않는다.

    SocketTimeout에는 아래 두 가지 옵션이 있고, 드라이버별로 설정 방법이 다르다.

    • Socket Connect 시 타임아웃(connectTimeout): Socket.connect(SocketAddress endpoint, int timeout) 메서드를 위한 제한 시간
    • Socket Read/Write의 타임아웃(socketTimeout): Socket.setSoTimeout(int timeout) 메서드를 위한 제한 시간

    CUBRID, MySQL, jTDS (Microsoft SQL Server), Oracle JDBC 소스를 모두 확인해 본 결과 네 개의 드라이버에서는 위의 두 가지 API를 사용함을 확인할 수 있었다. JDBC 드라이버별 SocketTimeout의 설정 방법은 아래와 같다. connectTimeout와 socketTimeout의 기본 값인 0은 타임아웃을 발생하지 않도록 하는 것이다.

    표 1 SocektTimeout 설정 방법

    JDBC 드라이버




    적용 방법




    MySQL Driver




    DriverURL에 옵션 명시

    • 형식







    jTDS(MS-SQL Server) Driver




    DriverURL에 옵션명시

    • 형식






    Oracle Thin Driver




    DriverURL로 설정할 수 없고, OracleDatasource.setConnectionProperties() API를 통해 Properties 객체로 전달해야 한다.

    DBCP사용 시 다음 API를 사용한다.

    • BasicDatasource.setConnectionProperties()
    • BasicDatasource.addConnectionProperties()




    Cubrid Thin Driver

    별도 설정 없음



    DriverURL로 설정할 수 없으며, 5초 후 타임아웃이 발생한다.

    • URL에 althost 옵션 지정으로 타입아웃 시 지정된 호스트로 연결 가능
    • C API로는 URL에 login_time 옵션을 ms단위로 명시 가능

    별도 설정 없음



    DriverURL로 설정할 수 없으며, 5초 후 타임아웃이 발생한다.

    • URL에 althost 옵션 지정으로 timeout 시 지정된 호스트로 연결 가능

    DBCP의 별도 API를 직접 사용하지 않고, Properties로 설정하는 방법도 있다. Properties 설정 시 키는 "connectionProperties", 값은 "[propertyName=property;]*" 형식의 문자열을 전달한다. 다음 예는 iBatis에서 XML을 통한 Properties 설정을 예로 들었다.

    <transactionmanager type="JDBC">
    <datasource type="com.nhncorp.lucy.db.DbcpDSFactory">
    <property name="connectionProperties" value="oracle.net.CONNECT_TIMEOUT=6000;oracle.jdbc.ReadTimeout=6000">
  • OS 레벨 SocketTimeout 설정

    SocketTimeout이나 ConnectTimeout을 설정하지 않으면 네트워크 장애가 발생해도 애플리케이션이 대부분 이를 감지할 수 없다. 따라서 연결이 되거나 데이터를 읽을 수 있을 때까지 애플리케이션이 무한정 기다리게 된다. 그러나 서비스에서 발생한 실재 장애 상황에서는 30분 후에 애플리케이션(WAS)이 재연결을 시도하여 문제가 해결되는 경우가 많다. OS에서도 SocketTimeout 시간을 설정할 수 있기 때문이다.

    이 기사의 처음에 예로 든 리눅스 서버에서는 SocketTimeout을 30분으로 설정해 두고 있었다. 해당 설정 값을 통해 OS 레벨에서 네트워크 연결 끊김을 확인하는 것이다. 문제가 발생한 리눅스 서버의 KeepAlive 체크 수행 주기가 30분이므로 SocketTimeout 설정을 0으로 해도 네트워크 장애로 인한 DBMS 연결 장애 지속 시간이 30분을 넘지 않는 것이다. Linux 서버에서 KeepAlive 체크 수행 주기는 tcp_keepalive_time로 조정할 수 있다.

    네트워크 장애로 인해 애플리케이션이 대기 상태로 빠지는 경우는 대부분 애플리케이션이 Socket.read() 메서드를 호출하고 있을 때이다. 그러나 네트워크 구성이나 장애 유형에 따라 매우 드물게 Socket.write() 메서드를 실행하는 도중 대기 상태에 빠지는 경우가 있다.

    애플리케이션에서 Socket.write() 메서드를 호출하면 OS 커널 버퍼에 데이터를 기록한 후 바로 제어권을 애플리케이션에 반환한다. 즉 커널 버퍼에 값을 제대로만 기록하면 Socket.write() 메서드 실행은 언제나 성공한다. 그러나 특수한 네트워크 장애로 OS 커널 버퍼가 가득차면 Socket.write() 메서드도 대기 상황에 빠질 수 있다. 이 경우 OS는 일정 시간 동안 패킷 재전송을 시도하다고 한계 값에 도달하면 에러를 발생시킨다. 이 기사에서 예로 든 서버에서는 해당 값이 대략 15분으로 설정되어 있었다. 이 값은 Linux 서버의 tcp_retries2로 조절할 수 있다.

  • 마치며

    JDBC 내부의 동작 설명은 이것으로 마무리한다. 올바른 타임아웃 설정으로 장애를 줄이는 데 도움이 되었으면 하는 바람이다. 추가적인 문의나 JDBC에 관련한 좋은 정보가 있다면 개발자센터 블로그나 이 기사의 댓글로 글을 남겨 주기를 부탁한다.

    마지막으로 자주 문의가 들어온 내용을 정리해 보았다.

    • Q Statement.setQueryTimeout() 메서드로 QueryTimeout을 설정했는데도 네트워크 장애 발생 시 기대하는 대로 동작하지 않습니다.
      A QueryTimeout은 정상적으로 소켓 연결을 맺고 있을 때에만 유효합니다. 그렇기 때문에 네트워크 장애의 예외 상황을 처리할 수 없습니다. 네트워크 장애 상황을 대비하려면 JDBC 드라이버에 있는 SocketTimeout을 설정해야 합니다.
    • Q TransactionTimeout, StatementTimeout, JDBC 드라이버 SocketTimeout은 DBCP 설정 값과 어떤 관계가 있나요?
      A DBCP에서 Connection을 JDBC로부터 얻어올 때 DBCP의 waitTimeout 값만큼 대기할 수 있습니다. 그 외의 DBCP 설정 값은 DBCP 단독으로 동작합니다.
    • Q JDBC SocketTimeout을 설정하면 DBCP에서 유휴 상태(idle)로 오래 유지된 Connection이 닫히지 않나요?
      A 아니요, 닫히지 않습니다. Socket 옵션은 실제 데이터를 쓰거나 읽을 때 적용되기 때문에, DBCP 안에서 유휴 상태인 Connecton에 영향을 끼치지 않습니다. DBCP 내부에서 부족한 Connection 생성, 오래된 유휴 Connection 제거, Validation Check 시 영향을 줄 수 있지만 네트워크에 문제가 발생하지 않는 한 특이 사항은 일어나지 않습니다.
    • Q SocketTimeout시간은 얼마나 길게 설정해야 하나요?
      A 본문에서 말한 것처럼 StatementTimeout보다는 충분히 크게 잡아야 하며, 권장 값은 없습니다. JDBC 드라이버의 SocketTimeout 값이 영향을 주는 시점은 네트워크 장애가 발생한 이후입니다. 해당 값을 정밀하게 설정한다고 해서 장애가 발생하지 않는 것이 아니며, 경우에 따라(네트워크 장애가 곧 복구되었을 경우) 장애 시간을 줄일 수 있을 뿐입니다.

    'Know > Java' 카테고리의 다른 글

    Netty ChannelGroup  (0) 2014.01.22
    Selenium을 이용한 UI 테스트  (0) 2013.06.11
    JDBC 동작 원리  (0) 2013.02.22
    Java Troubleshooting Tool - VisualVM  (0) 2013.02.13
    m2 eclipse 버전업시에 에러 ignore  (0) 2012.02.24
    Eclipse ERD Plugin  (0) 2011.01.12
    Trackbacks 0 : Comments 0

    Java Troubleshooting Tool - VisualVM

    Know/Java 2013.02.13 17:42


    java thread 정보를 분석할 수 있는 visual tool.


    다운로드는 아래!




    'Know > Java' 카테고리의 다른 글

    Selenium을 이용한 UI 테스트  (0) 2013.06.11
    JDBC 동작 원리  (0) 2013.02.22
    Java Troubleshooting Tool - VisualVM  (0) 2013.02.13
    m2 eclipse 버전업시에 에러 ignore  (0) 2012.02.24
    Eclipse ERD Plugin  (0) 2011.01.12
    Maven local Repository에 custom jar 추가하기  (0) 2010.10.07
    Trackbacks 0 : Comments 0