[postgresql] postgresql.conf 설정항목 설정

안녕 하세요? 조성준 입니다. 

PostgreSQL 8.0 기존 .설정파일인 postgresql.conf의 설정 설정 입니다 

만들다 말다 하다보니 쩝., 8.0이 나오니 양만 늘었네요. 이리 올렸으면, 바뀌건만 하면 되는데 
워낙 실력이 미천하고 독학에 되도않는 영어와 사전으로 주어들은거나 본거로 
아는 범위내에서 설명을 드렸습니다. 

모르는것은 찾아 해메서 이해된건만 기명했으며, 틀린내용은 당연히 듬뿍 많을것입니다. 
혹여 튼린부분이 보이시면 지적해주시면 많은 도움이 될것입니다.^^ 
- FILE LOCATIONS - 

시스템과 직접 연관된 파일들에 대한 설정 

data_directory = 'ConfigDir' 


    실제적인 PostgreSQL의 DB Data 폴더 설정입니다. 
    PostgreSQL 는 기본적으로 접근자 Shell의 환경변수중 PGDATA에 대해서 로딩하게 됩니다. 
    이걸 설정하면 PGDATA Enviroment가 없을때 잡게 되나 계정별로 주시는것인 
    다소 낳을것 같습니다. 



hba_file = 'ConfigDir/pg_hba.conf' 


    PostgreSQL의 접근제어 파일인 pg_hda.conf입니다. 이부분은 다른 장에서 자세히(과연-.-;)설명드리겠습니다. 



ident_file = 'ConfigDir/pg_ident.conf' 


    PostgreSQL의 Ident Authentication Maps 파일로 이역시 다른장에서.Comming Soon>. 



external_pid_file = '(none)' 


    PostgreSQL의 Process ID파일위치인데 기본적으로 PGDATA 또는 data_directory 쪽에 
    postmaster.pid 파일로 생성되며, Shutdown등에 이용되며, 따로 설정하지 않아도 됩니다. 




CONNECTIONS AND AUTHENTICATION - 

접속과 인증관련 

listen_addresses = 'localhost' 


    PostgreSQl 의 Listen Adress설정으로 Default Localhost로 되어 있다. 이경우 PostgreSQL가 장착된 
    서버 로칼만 가능하면 외부접근이 되지 않습니다. 

    '*' (아스타)로 줄경우 해당 장비의 Network Interface에 설정된 정보 모두를 허용하므로, 모든접근이 가능, 

    만약에 서버 네트웍카드가 듀얼이나 다중일경우 IP셋팅을 여러개 한다. 
    만약에 192.168.0.10 , 192.168.0.11 , 192.168.0.12 , 192.168.0.13 번이 있다고 칠때. 

    192.168.0.10 과 192.168.0.13 으로 설정된 Network 으로만 들어오게 하고 싶은때는 
    listen_addresses = '192.168.0.10.192.168.0.13' 식올 ,(콤마)구분으로 가능하다. 



port = 5432 


    PostgreSQL의 Service Port를 지정하는 것으로 기본 5432포트로 되어 있으나 변경도 가능하다. 
    외부에 노출되어 있는경우 바꾸어주는것이 좋을듯 하다. 



max_connections = 100 


    최대 동시접속자의 수를 정하는 부분인데 이는 다소 주의해야하면 Shared Memory설정에 민감하면 1명당최소 500Byte가 필요하다. 
    이부분의 설정은 Performace 쪽 장에서 알려드리겠습니다.(이글 올리고 언제쯤 쓸지원 ^^) 



superuser_reserved_connections = 2 


    Superuser Reserved 의 영어처럼(전 영어 땝따 모름,중.고를 잠만자져,사전으로 봤음 음..) 

    SuperUser의 접속을 위한 예비용으로 설정하는 것으로 Max Connection설 정이 100일떄 이를 2로하면 98명만이 
    동시접근되고 2명동시접속이 가능하다. 되도록이면 설정하는것이 좋다. 

    접 속량 폭주시에 어떤한 상황대처때 psql -U postgres 디비 했는데 너줄 자리없어. 나가있어~라고 토설하면 
    매우 당황스럽지요. 




unix_socket_directory = '' 


    TCP/IP 접속만이아닌 Local에서는 Unix Socket 으로 접속이 가능하며 네트웍보다는 좀 낳은 성능을 보이긴한다. 
    이 설정을 해주지 않으면 /tmp에 .s.PGSQL.5432 과 .s.PGSQL.5432.lock 파일이 생성됩니다. 
    5432를 보든이 해당포트로 만약에 한 서버에 PostgreSQL를 여러개 띄울때 구분을 위함이다. 



unix_socket_group = '' 


    Unix Socket파일의 Onwer는 역시 PostgreSQL Master User이지만 Group을 정할수 있다. 
    접근 제어를 시스템단계에서도 할수 있기 위한 배려, 미설정시 PostgreSQL Satart한 Master User의 
    Owner와 Group을 따라 간다. 



unix_socket_permissions = 0777 octal 


    역시 시스템 Permission차원의 접근제어를 위한 퍼미션 설정이다.따로 설정하지 않을시 srwxrwxrwx 로 설정된다. 



rendezvous_name = '' 



- Security & Authentication - 

authentication_timeout = 60 


    인증 오류시의 재인증까지의 TimeOut으로 기본 60초이며 초단위 설정이 가능하면 문서를 보면 600초(600/60=10분)까지 
    됩니다만. 설정을 하실시 짧게 주시되 상황에 따라 주시면 되지만 너무 길게주면 오히려 리소스만 잡아 먹습니다. 



ssl = false 


    SSL 인증처리 여부체크로 이 옵션은 여기서 설명보다는 pg_hda.conf 설명떄 다시 드리겠습니다. 



password_encryption = true 


    create user나 alter user로 계정 생성 변경시에 ENCRYPTED혹은UNENCRYPTED로 지정하지 않을때 자동으로 
    Password Encryption할지 여부를 주는 것으로 디폴트로 두시는것이 



krb_server_keyfile = '' 


    Kerberos 서버 키파일의 위치정보 설정으로 커버OS쪽 설정은 따로 자료를 구해보셔요. 제가 잘모르는 부분이라., 



db_user_namespace = false 


    User 별 디비설정때 사용하는 옵션으로 Oracle의 SID와 같은 형태라고 보면 쉬울듯하다. 
    기존에는 계정하나로 보통 다 접근이 되나 이경우는 계정@디비명 식으로 접근을 모두 해야 합니다. 




- RESOURCE USAGE (except WAL) - 

PostgreSQL운영 리소스 제어 


shared_buffers = 16 


    공 유메모리의 설정으로 max_connections수의 2배는 설정을 해주어야 하며, OS의 Shared Memory 설정까지만 설정이 가능하다. 
    SHM* 커널 파라미터와 연관되어지면 Performance 설정과련 장에서 다시 설명드리겠습니다. 

    권장사항은 최소 1,000단위로 설정을 해주는것을 추천합니다. 실제로는 이정도는 너무작아 보인다. 
    1 = 8Kb(8192Byte)를 먹기때문에 잘계산해야 하는데 공유메모리 설정과 셋팅관련은 따로 장으로 알려드려야 할부분으로 
    다소 고민을 해야한다. 




work_mem = 1024 


    말그대로 작업용 메모리 상한선을 지정하는 것으로 Sorting(Order by),Distinct시나 , In,merge join등 결과를 만들어내기위해 
    쿼리에 해당되는 정렬이나 임시 저장을 위한 공간 확보의 상한선을 주는것으로, 
    이는 모든 합계를 정하는게 아니라 각 쿼리당으로 설정값이 반영되므로 무턱대로 많이 주면 시스템 메모리가 
    커질것입니다. 작업상에 어느정도를 잡아야 하나 실제 쿼리 수행후 나오는 데이타들의 크기를 대략보고 정하면됩니다. 
    KiloByte당위 설정으로 기본값은 1024kb나 최소 64까지가능하나 디폴트나 조금더 주면 충분하나 
    업 무량에 따라 늘력주시되 주의할것은 총합이 아닌 각각의 쿼리질의당이므로 주의요망!! (메모리가 무리 넉넉하시면 많이 주면 성능의 향상 
    이 있습당) 



maintenance_work_mem = 16384 min 1024, size in KB 


    DML즉 Create , Alter등 실제적인 관리 목적의 작업이나 vauum시의 작용 메모리 사용 제한선으로 work_mem 설정보다는 쬐금더 
    현재 기본값은 약 16M정도로 많이 사용하는 부분은 아니지만. 복구작업이나 DML쿼리 전송이 많을때 많이 주면 빠른 처리가 된다. 
    그리크게 설정할필요까지는 없으니 디비 엎고 다시 넣거나하실때에는 높여 주시면 성능 향상이 됩니다. 



max_stack_depth = 2048 min 100, size in KB 


    최대 Stack 수로 아무리 많이 준다해도 Kernel설정을 최대치로 놓으니 ulimit 로 설정시에는 많이 줄수 있으나 
    이는 너무많이주면 Crash가 일어날수 있습니다. 재귀호출함수나 복잡한 함수처리에는 조금더 설정해주면 좋으나 
    부턱대로 늘리는건 비추천입니다. 역시 KiloByte단위이면 기본이나 기본보다 조금더 주는게 좋을것 같습니다. 



- Free Space Map - 


    max_fsm_pages = 20000 min max_fsm_relations*16, 6 bytes each 
    max_fsm_relations = 1000 min 100, ~50 bytes each 

    정확한 용도를 모르겠음 T.T누가 알려주세요.! 



- Kernel Resource Usage - 

PostgreSQL이 Kernel 리소스 이용에 대한 제어 

max_files_per_process = 1000 min 25 


    각 PostgreSQL Process(Child Process)가 Open할수 있는 최대 파일수 입니다. 이는 Kernel설정값 file-max와 연관된것으로, 
    Kernel에서 제한을 했다면 설정을 않해도 되지만 Unlimit로 되어 있거나 file-max로 이미 잡아 놓은 상태에서 
    그 범위내에서 처리할떄 조정하는것으로 너무 많이 설정하면 , 커널에서 너 너무열었어. 닫어~ 쨔샤 라고 에러가 나니 
    너무 높게는 잡지 마시구요, 요즘은 Ulimit로 설정이 많으니 높게 주셔도 큰무리는 없을듯. 



preload_libraries = '' 


    PreLoad 서버 Start시에 함께 메모리에 적재할 Library를 설정하는 것입니다. 

    PL(Procedure Language) Library에 대해 미리 설정하면 PL 로 작성된 함수들의 처리에 빠른 속도를 낼수있습니다. 

    문 법은 '$libdir/plXXX:plXXX_init' 식으로 python 라이브러리를 Start시점에서 적재하고 싶으면 
    '$libdir/plpythoni:plpythonu_init' 식으로 하시면 됩니다. $libdir은 PostgreSQL설치위치에서 자동으로 찾아오나 

    해당 라이브러리가 다른곳에 있으면, 위치를 절대 경로 (/usr/local/lib)로 주시면 되면 여러개를 하실때는 
    ,(콤마)구분으로 하시면 됩니다. 




- Cost-Based Vacuum Delay - 

Vauum에 대한 

vacuum_cost_delay = 0 0-1000 milliseconds 
vacuum_cost_page_hit = 1 0-10000 credits 
vacuum_cost_page_miss = 10 0-10000 credits 
vacuum_cost_page_dirty = 20 0-10000 credits 
vacuum_cost_limit = 200 0-10000 credits
 


    PostgreSQL 의 단편작업과 오류수정과 최적화를 위해 vacuum을 실행하는데 
    이 실행시 잠시 데이타에 Lock이 되거나 Delay가 생겨 본 작업수행에 다소 
    지장을 주는데 위 설정으로 Delay를 주어 다른 쿼리가 이미 수행중이거나 
    Transaction 처리중에 Delay를 주거나 허용된 범위 이상으로 리소스를 찾지 않게 하는것입니다. 
    실제적인 update,delete..등이 자주일어나거나하면 당연히 vauum해주어야만 한다. 
    이때 select 쿼리가 상당량을 차리할때 vauum을 해주면 딜레이가 생기니 

    적당성으로 실시간이나 한가한시간대가 아닌 시간단위등으로 할경우는 이옵션으로 
    본래의 Transaction에 최대한 지장을 주지 않도록 셋팅하면 좋습니다. 



- Background writer - 

BW에 대한 제러 

bgwriter_delay = 200 10-10000 milliseconds between rounds 
bgwriter_percent = 1 0-100% of dirty buffers in each round 
bgwriter_maxpages = 100 0-1000 buffers max per round
 


    역시 성능향상을 위한것으로 write Process의 Delay타임과 전체 리소스 퍼센트와 
    일정량까지 BackGrount Write가 시행됭 Buffer량을 설정하는 부분입니다. 
    이것역시 시스템 사용량과 용도에 따라 적절히 설정하면되나 주석처리된 상태로 써도 
    문제될것은 없습니다. 



- WRITE AHEAD LOG - 

WAL에 대한 제어 

fsync = off 


    상당히 처음 Config파일을 보고 당황한것은 기본설정에 true이고 옆에 코멘트는 on,off란다. 
    얼마가 고민했던지 하지만 ini Config Style이며, 어차피 Config Parser에서 처리하므로 
    on,off든 true,false든 결과는 값습니다. 

    fsync를 on(true)일 경우 Disk Write가 빈번히 일어나고 바로바로 Sync되므로, 
    성능(빠른 응답)을 원할때는 off(false)가 좋으나 안정성만을 위한다면 on(true)가 안정하다. 

    시스템 Crash로 인한 복구에 롤백시점이 생기지 않기를 원한다면 on(true).얻는게 있으면 잃는게(속도~) 있습니다. 



wal_sync_method = fsync 


    WAL의 File Sync 시의 방법에 관한것으로 디폴트 fsync입니다. 
    fsync 이외에 fdatasync , open_sync or open_datasync가 있습니다 

    OS자체의 파일 함수를 쓰는데 open_sync는 O_SYNC로 WAL Log파일을 오픈하고 
    open_datasync는 O_DSYNC로 WAL Log를 오픈한다. 

    자세한건 따로 설명드리겠습니다. C나 python으로 OS차원의 File Control해보신분은 의미를 아실듯. 





wal_buffers = 8 


    WAL 의 버퍼 설정으로 최소는4로 실제 쓰는 메모리의 량은 4*BKbyte이다. 
    디폴트로 두어도 상관없으니 쿼리속도만을 생각한다면 버퍼를 늘리면 좋겠지만. 
    버퍼에 너무많이 가지고 있닫 Power Down이 올경우 그마만큼 복구시점의 손해가 오니 
    기본값이 일반적으로는 좋을것 같다. 



commit_delay = 0 


    WAL 의 Commit(Disk Write) Delay설정으로 마이크로 세컨드설정으로 최대 10,0000 까지된다., 

    WAL Buffer 설정 크기만큼 WAL Log를 담고있다 넘칠때 실제 물리적 Disk에 Write할깨의 Delay시간입니다. 
    MicroSecound 는 백만 분의 1초단위이다. 음. 초이하로 내려가면 난감함. 0.1단위까지는 감이오지만 ^^ 




commit_siblings = 5 


    ?? 아직도 이해못하고 있음 ^^ 



- Checkpoints - 

체크 포인트에 대한 제어 

checkpoint_segments = 1 


    WAL의 체크포인트를 찍는 최대 거리를 정하는 것으로 , 1 세그먼크당 약 16MB(16*1024의 텀이 생깁니다. 
    즉 이 값을 많이 주면 복구시점의 PITR이 너무 많은 컴을 가지게 됩니다. 
    기 본 3이지만 1을 추천해 드립니다. 또한 Check Point Segments를 너무 많이 주면 
    그 용량이 찰때까지의 성능 향상은 있으며, 뭐 몰아서 벼락치기라고 하는게 맞을것 같습니다. 
    짧게 주시길 권장.! 



checkpoint_timeout = 300 


    WAL Auto Check Point 간격의 시간을 정하는 것으로 , 초단위 설정을 하시면 됩니다. 
    디폴트는 300초입니다. 너무 자주 찍어도 그렇고 너무 넓게 찍어도 그렇지만 시스템의 Transaction량이 
    분단위 처리량이 만은지 시간당 처리가 많은지와 최악의 상황의 복구시점들을 생각해서 적어 주시데 
    역 시 너무 짧아도 좋지 않고 너무 넓어도 나머지공부와 벼락치기를 하게 된다. 



checkpoint_warning = 30 


    경고 메세지로 checkpoint_segments에 설정된 크기에 넘칠때 해당 시간내에서 
    Write후 Flush즉 비워지지 않고 계속 흘러 넘칠때 경고메세지를 에러 로그에 남기에 하는 옵션입니다. 
    0 은 off이며 초단위 설정이며, 처음 WAL과 PITR의 주기와 셋팅을 체크하실때 켜두시면 어느정도 튜닝에 도움이 되실겁니다. 



- Archiving - 

WAL에 대한 Archive 제어 

archive_command = '' 


    WAL Log파일등의 백업처리등에 쓰는것으로 DAT나 기타 백업 미디어나 백업 Disk쪽으로 백업하는 일련의 시스템 Command입니다. 
    문법은 다음과 같습니다 



archive_command = '/bin/cp -i %p /mnt/tape/%f > /var/log/wal-log-archiving.log' 


    식 으로 사용하는데 문자열 포맷팅에는 2가지가 있는데 
    %p 는 WAL Log Archive 절대경로+파일명이며, %f는 WAL Log 
    Archive File명입니다. 
    Command Line작성히 Systeam 명령을 내리는것으로 모두다 절대경로로 사용하십시요.!!! <-- 겁나게 주의요망 




- QUERY TUNING - 

쿼리튜닝 실행관련 제어 

- Planner Method Configuration - 

이옵션은 자주 analyse나 vacuum등으로 각종 쿼리에 대한 탐색 최적화 plan을 해주는 기능으로 무조건 True로 두는게 
좋다고 권장해드립니다. 만약에 쿼리가 100,000만 쿼리르 뒤지는데 첫 실행후 2번째는 최적의 결로를 찾아 1,000레코드만 뒤지는등 
성능 향상을 보여줍니다. 

enable_hashagg = true : 일반적인 쿼리 Auto Plan 
enable_hashjoin = true : Joint쿼리 Auto Plan 
enable_indexscan = true : Index Scan Auto Plan 
enable_mergejoin = true : Merge Join Auto Plan 
enable_nestloop = true : Nest Loop Auto Plan 
enable_seqscan = true : Sequence Scan Auto Plan 
enable_sort = true : Sort Auto Plan 
enable_tidscan = true : TID Scan Auto Plan 

위 옵션은 seqscan과 nestloop의 경우 index scan보다 오히러 느려지는 경우가 있어 false로 두어야 할떄가 있습니다. 
explain analyse 쿼리; 를 통해 어떤 쪽이 탐색에 더 유리하신지에 따라 Default값을 변경해주싶시요.
 


- Planner Cost Constants - 


    이 부분은 아직 안정화된 부분이 아니라는 군요. 조금 두고보고 설명드리겠습니다. 

    effective_cache_size = 1000 typically 8KB each 
    random_page_cost = 4 units are one sequential page fetch cost 
    cpu_tuple_cost = 0.01 (same) 
    cpu_index_tuple_cost = 0.001 (same) 
    cpu_operator_cost = 0.0025 (same) 



- Genetic Query Optimizer - 

GEQO 쿼리튜닝 실행관련 제어 

geqo = true 


    Genetic Query Optimizer의 가동여부 결정. 위의 결과적 튜닝이 아닌 유연한 쿼리 튜닝이라고 합니다. 
    정확히 어떻게 처리된는지는 좀더 조사중입니다.^^~ 



geqo_threshold = 12 


    Query문에서 From 절의 갯수제한으로 12개 이상의 From이 들어간 쿼리에 대해 Genetic Query Optimizing을 합니다. 



geqo_effort = 5 


    GEQO의 쿼리 최적화 Plan시의 여러가지를 해보는 그범위를 설정하는것입니다. 많이주면 그마만큼 최적화는 되겠지만. 
    괜한 시간 소비가 일어 납니다. 최대 10, 기본값(5) 정보다 적당할듯 싶네요. 
    아 래 옵션들이 0을 설정시 최대값 근거치정도로도 사용됩니다. 



geqo_pool_size = 


    GEQO 가 사용할 Pool Size로 보통들 100~1,000정도 쓴다고 문서에 되어 있네요. 쩝.! 
    0으로 두면 geqi_effort의 값과 쿼리에서 호출하는 Table의 수를 감안해서 자동 계산하니 귀찮으신분은 0 추천 ^^ 



geqo_generations = 0 


    GEQO 최적화 알고리즘의 최대 루프수입니다. 0 설정시 geqo_effort 를 참조하게 됩니다. 



geqo_selection_bias = 2.0 


    1.5 에서 2.0까지 설정되면 Selection Bias.. 음 잘 모르겠음. 편향값 제어음..^^ 영어 공부합시다. 



- Other Planner Options - 

default_statistics_target = 10 


    위 Query Optimize Planner(,ALTER TABLE SET STATISTICS) 에서 처리되지 않는 쿼리에 대한 쿼리최적화로 
    값증가는 역시나 많은 시간을 소요하지만 최적화 될가능성도 있기는하니 적절히 상황에 맞게 사용하길 바랍니다. 



from_collapse_limit = 8 


    이 옵션은 geqo_threshold 보다 적은 수를 주러 geqo_threshold 보다 적은 from 절을 가진 쿼리에 대한 최적화를 단행 합니다. 



join_collapse_limit = 8 


    위와 같은것으로 쿼리의 Join절대 대한 최적화를 단행한다고 생각 하시는게 쉬우실듯. 




ERROR REPORTING AND LOGGING 

에러 리포팅과 로깅관련 제어 


- Where to Log - 

log_destination = 'stderr' 


    서버 로그에 대해 어디로 출력할것인데 기본이 Standard Error로 출력된다. 
    화면에 출력됩니다. 하지만 syslog시에는 아래 syslog_**옵션의 영향을 줍니다. 

    따로 로그 서버를 두시는 분들은 syslog로 놓고 syslog_** 옵션을 통해 외부서버로 전송하시는것도 
    좋은 방법입니다. 



redirect_stderr = true 


    이 옵션은 아래와 직관적인 영향으로 로그에 대해 stderr에 대해 아래 설정된 로그파일처리시에 
    Standard Error로 출력된것으로 모두다 로그파일화 하느냐의 옵션으로 서버가 눈앞에 있지 않는이상 
    로그로 Redirect하는게 나중에 Manternence에 매우 유익함다. 



log_directory = 'pg_log' 


    Log 파일을 저장할 디렉토리지정으로 당연히 PostgreSQL 의 Owner와 Group그리고 Permission이 설정된 
    디렉토리여야만 합니다. 기본적으로 상대결로를 주시면 PostgreSQL의 Data Folder에 pg_log식의 폴더가 생기면 
    따로 저장을 워하시면 절대 경로 /dep/log/pgsql 식으로 설정해주시면 됩니다. 




log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' 


    에러 로그파일에 대한 Log Rotate File구성으로 위와 같이 설정하면 

    postgresql-년(4자리)-월-일_시분초.log 로 생성된다. 만약에 분단위나 일단위로 하고 싶으시면 
    log_filename = 'postgresql-%Y-%m-%d-%H.log' 식입니다. 



log_truncate_on_rotation = false 


    이 옵션을 아래 두개의 옵션을 통해 로그파일을 나누는 옵션으로 log_filename 에 지정한 형식이 아닌 
    파일 생성시간 부터의 시간이나 FIle Size를 통해 로그를 나눌때 씁니다. 
    저는 별로 추천하지는 않는 옵션으로 보통 log_filename으로 일단위나 시간단위로 남기는 편입니다. 



log_rotation_age = 1440 


    로그파일이 최초 생성시점부터 1440초 이상지나면 다른파일이 생성되게 한다. 
    0 은 Disable입니다. 



log_rotation_size = 10240 


    로 그파일의 크기로 제안하는 것으로 10240byte명 1Mb단위로 파일을 나누어 저장하는것입니다. 




syslog_facility = 'LOCAL0' 


    에러 로그를 syslog로 설정시 syslog daemon의 facility를 주어주는 것으로 LOCA0~7까지 있다 기본적으로 시스템에서 LOCAL7에 대해서 
    는 
    부팅로그를 남기니 겹치지 않게 셋팅하시고 쓰시는 syslog daemon문서를 보심이 좋다고 하네요. 



syslog_ident = 'postgres' 


    Syslog 저장시 구분용 단어로 PostgreSQL DB 뭐 이런식으로 두실수도 있습니다. 식별용 키워드이니 적당한걸로 셋팅 




- When to Log - 

로그 생성에 대한 제어 

* 에러 로그 레벨 설명 * 

인용 또는 결과 : 

DEBUG[1-5] : 실제적으로는 필요없으나 PostgreSQL 개발자들에게 필요한 정보라고 보면 됩니다. 

INFO : 유저레벨로 단순히 유저쪽에 알리는정보 

NOTICE : 유저에게 유용하게 알수 있거나 단순히 이렇게 하는게 좋겠어? 이건 주위해라는 정보 

WARNING : 유저 경고정도, 이건 어떻게든 처리해라던지 Transaction Start가 않되었는데 Commit을 한다던지하는 경고성

ERROR : 현재의 업무수행을 중단할정도의 에러 

LOG : 관리자에게 필요한 정보류, 체크리스트 활동정보라던지 실질적인 DBA용 메세지 

FATAL : 현재의 쿼리 세션을 중단하게 하는 에러 

PANIC : 모든 세션에 대한 중단이 초래되는 원인에 대한 에러 

[root@good /root]$ 
_



client_min_messages = notice 


    debug5, debug4, debug3, debug2, debug1, 
    log, notice, warning, error 

    로그 기록상의 로그 Level의 설정하는 것으로 디폴트인 Notice를 두면 

    Notice,Warning,error 로그에 대해서 Client에서 전송합니다. 너무 높게 설정하면, 
    그 엄청난? 에러는 다박고 우엑하기 때문에 디폴트가 적당선인것 같습니다. 



log_min_messages = notice 


    debug5, debug4, debug3, debug2, debug1, 
    info, notice, warning, error, log, fatal, 
    panic 

    위와 같으면 이는 서버에 로그 기록 레벨을 정하는 것입니다. 



log_error_verbosity = default 


    terse, default, or verbose messages 

    이 것은 로그 기록시의 해당 오류에 대한 정보에 대한것으로 terse로 설정하면 최대한 많은 에러로그에 대한 
    정보는 받을수 있으면 default와 verbose는 같은 옵션입니다. 

    서버 Transaction이 말고 terse 레벨로 로그를 남겨 상세히보고 싶으시면 Log Directory를 다른 하드디스크로 
    두시는 편이 좋습니다. 



log_min_error_statement = panic 


    debug5, debug4, debug3, debug2, debug1, 
    info, notice, warning, error, panic(off) 

    사용자의 쿼리에 대한 에러로그로 레벨로 설정값 아래 수위일때 저장됩니다. 
    만약에 DB Application에서 쿼리 Fail에 대한 정보를 따로 수집않하시면 
    레벨을 올려 서버에 남겨서 하셔도 됩니다. 



log_min_duration_statement = -1 


    이 옵션을 지정된 시간이상 Client의 질의 쿼리에 대해 작업할때 로그를 남깁니다. 
    이건 초기 개발이란 런칭한지 얼마 않되거나 Tunning시점에서 품질 기준시간을 설정해 
    너무 지체되는 쿼리에 대해 Tunning할때 필요합니다 -1은 Disable이면 
    밀리세컨드로 지정할수 있습니다. 



silent_mode = false 


    slient 즉 조용하게 에러는 redirect로 Log Write하지 않을경우 주위 즉 기본옵션으로는 화면에 에러 출력을 하는데 
    이걸 그냥 true하면 에러나도 아무런 메세지를 볼수 없다. 주위를 좀 요합니다.(제가 그런적있거든요 쩝) 




- What to Log - 

로그 데이타 생성의 부분 제어 

debug_print_parse = false 
debug_print_rewritten = false 
debug_print_plan = false
 


    Debug 레벨 설정시에 문법Parsing, ReWrite,Plan에 대한 디버깅정보 출력 여부설정으로 레벨을 Debug[1-5]가 아니면 
    별 의미가 없습니다. 



debug_pretty_print = false 


    Debug Level에서의 에러 로그시에 좀더 자세히 보기 쉽게 할때,즉 풀어서 보여준다는 걸로 이해하셔용 



log_connections = false 


    접속 로그 



log_disconnections = false 


    접속해제 로그 



log_duration = false 


    ??? 



log_line_prefix = '' 


    로그 기록시 여러분이 원하는 패턴을 정하면 로그의 각줄에 정한 패턴의 형식의 데이타가 앞에 붙어 
    좀더 라인단위 로그분석에 용의 합니다. 
    인용 또는 결과 : 

    %u : 접속유저명 
    %d : 디비명 
    %r : 리모트접속자의 HostName (Resolve)또는 IP와 Port 
    %p : 프로세스 ID 
    %t : Unix TimeStamp (일반적으로 사람이 보기 쉬운(흔한) 형태의 시간 
    %i : command tag 
    %c : session id 
    %l : session line number 
    %s : session start timestamp 
    %x : transaction id 
    %q : stop here in non-session processes 
    %% : '%' <- 문자열 포맷팅 구분자로 %를 쓰니 쓰고 앂으시면 %%로 쓰셔야 만 합니다. 

    [root@good /root]$ 
    _



log_statement = 'none' 


    SQL쿼리 로그시에 원하는 부분만 남기고 싶을때 none은 아무것도 하지 않으면 
    mod(DML)(insert,update,delete,trunscate,copy from,prepare,explain등) , ddl (create,aler,drop),all은 ALL ^^ 



log_hostname = false 


    로그에서는 기본적으로 접속자IP를 기록하나 이걸 true화 하면 resolve또는 hostserver search(/etc/nsswaitch 설정기준으로)를 해서 해 
    당 
    IP에 대한 Host명을 찾는데 저로써는 하지 않으시길 바랍니다. 

    만약에 배포용 Visual Application에서 Danymic DNS 처엄 IP는 다르지만 Host명을 가지고 있는 경우 남기고 싶으시면 모르지만 
    일반적으로는 로그 하나 남길때마다 조회를 해야 하니 음... T.~; DNS Cache Server나 빵빵 하시면 해보심도. 암튼 비추 




- RUNTIME STATISTICS - 

실행시 통계정보 제어 

- Statistics Monitoring - 

log_parser_stats = false 
log_planner_stats = false 
log_executor_stats = false 
log_statement_stats = false
 


    위 옵션은 각각의 상황에 따라 로그를 남기느냐 입니다. 



- Query/Index Statistics Collector - 

stats_start_collector = true 


    통계정보 수집용 Process를 기동시킬건지에 대한 옵션 



stats_command_string = false 


    각 접속된 세션의 Command String즉 쿼리문에 대한 통계정보 수집여부로 , 메인 관리자나 로그수집 유저가 아닌이상 
    다른이가 볼수없어 보안상 위험은 없다고 합니다. 
    시스템 카타로그인 pg_stat_activity 를 통해 감시감독이 가능 합니다. 



stats_block_level = false 


    디비 활동에 대한 Block Level의 통계정보수집여부로 시스템 카라로그 테이블 pg_stat와pg_statio를 통해 감시가능 



stats_row_level = false 


    위와 동일하면 row Level에 대해서 



stats_reset_on_server_start = true 


    지금까지 설정한 정보를 서버 리스타트시 사제 할것인지 여부를 지정하는것 




- CLIENT CONNECTION DEFAULTS - 

유저 접속과 관련된 기본 설정 

- Statement Behavior - 

search_path = '$user,public' 


    ??? 



default_tablespace = '' 


    사용자의 TableSpace 디폴트로 설정이 가능 합니다. 기본적으로는 pg_global즉 시스템의 PGDATA 폴더로 TableSpace로 사용하나 
    이를 따로 바꿀수도 있습니다. 
    즉 시스템과 직결과것은 PGDATA 환경변수나 맨위 data_directory로 잡고 , 유저들의 사용 Table Space는 create tablespace등으로 
    따로 잡지 않고 Config 파일 단위에서 처리 할수도 있습니다. 



check_function_bodies = true 


    create function 내부 문법에 대한 오류체크선택,기본적으로는 true를 해야만합니다. 그래야 나중에 쌩뚱맞은에러에 대처하죵.~네~ 




default_transaction_isolation = 'read committed' 


    Transaction 처리 Mode에 대한것으로 트랜잭선 모드에 다른 접근자의 접근시의 허용여부로 
    옵션은 read uncommitted,read committed,repeatable read or serializable 을 지원합니다. 

    각가 레벨은 http://www.postgresql.org/docs/8.0/interactive/transaction-iso.html 을 참조 하십시요. 



default_transaction_read_only = false 


    디폴트로 Transaction 수행중일때 해당 Table에 대한 Read Only설정 여부입니다. 
    set transaction 으로 각업무별로 주는것이 효율적인듯. 



statement_timeout = 0 


    지정된 시간이상의 쿼리에 대해서는 모두 중단 시켜 버립니다. 0은 Disable이고 셋팅은 milliseconds로 하시면 됩니다. 



- Locale and Formatting - 

지역화와 각종 포캣팅관련 제어 

datestyle = 'iso, mdy' 


    날짜 포맷에 대해 입력이나 출력시의 포맷에 대한 기본설정입니다. 
    다음은 지원되는 포맷들의 출력 예입니다. 

    ISO(ISO 8601) : 1997-12-17 07:37:16-08 
    SQL : 12/17/1997 07:37:16. 00 PST 
    POSTGRES : Wed Dec 17 07:37:16 1997 PST 
    German : 17.12. 1997 07:37:16. 00 PST 



    뒤의 mdy는 기본 출력 양식으로 Month Day Year로 월일년 출력순으로 변경은 가능 합니다. 




timezone = unknown 


    시스템의 TimeZone기준으로 unknown으로 하면 System의 설정된 Time Zone기준입니다. 



australian_timezones = false 


    australian TimeZone이 좀 일반적인 TimeZone과는 좀 달라 배려용 옵션인데 잘모르겠네용 -.-; 
    날 오스트레일리아로 보내준다면야~ ^^ 



extra_float_digits = 0 


    부동소숫점의 소숫점아래의 길이를 제한하는것으로 -15로 하면 0.000000000000000 까지 가능하다. 
    0으로 부터 Data Type에 맞추어 지므로 특별히 제한을 주고 싶으실때 정하시면 됩니다. 




client_encoding = sql_ascii 


출처 : http://xshine.tistory.com/229

페이스북은 어떻게 개발하고 배포할까?

전세계에서 재능있는 엔지니어들이 몰려있다는 실리콘밸리 기업들 중에서도 페이스북은 놀라운 개발생산성을 보여줍니다. 개발자 한명이 대응해야 하는 액티브 사용자 수가 구글의 5배, 아마존의 10배가 넘습니다. 페이스북의 개발 프랙티스는 많은 기업들에게 연구의 대상이자 롤 모델이 되기도 합니다. 2013년 2월 IEEE에 "Development and Deployment at Facebook"라는 논문을 통해 페이스북에서의 개발과 배포 방법을 살펴볼 수 있습니다. 3명의 저자가 쓴 글인데 그중 한명은 XP의 창시자로 유명한 Kent Beck입니다. 2013년부터 페이스북에서 근무하고 있습니다.  

여담으로 Kent Beck이 2013년 페이스북 채용 인터뷰 과정에서 8 Queens라는 체스전략퍼즐을 풀기 위해 25년 전의 Prolog 자연언어처리 기술까지 끄집어내느냐고 진땀을 흘렸다는군요. 페이스북 내부 채용팀의 능력과 공정성을 칭찬하면서 자기가 채용팀에 이런 얘기를 할 줄은 몰랐다고 합니다. 


[개발자당 활성 사용자 수, 자료: Facebook-Moving-Fast-at-Scale]


1. Perpetual Development 

페이스북에는 완성이라는 것이 없습니다. 다른 인터넷 기반 기업들처럼 페이스북도 지속적인 개발 모드로 끊임없이 새로운 기능을 개발하여 사용자에게 제공해야 합니다. 지속적 개발을 위해 성장과 빠른 배포는 엔지니어가 반드시 해결해야만 하는 과제라고 할 수 있습니다.  

                                                              [개발주기의 시간척도]

폭포수 모델은 전체 개발사이클을 통해 최종 제품을 한번에 전달하는 것이 목적이라면, 애자일에서는 주단위로 릴리즈 혹은 점진적 개발을 가져갑니다. 페이스북은 제품을 매일 릴리즈하며 빠르게 개발과 배포를 수행하며, 지속적 배포는 정말 하루에도 수십번씩 프러덕션에 반영하는 것입니다. (delivery는 운영서버에 릴리즈 대기상태로 만들어 놓는 것으로, deployment는 실제 사용자에게 서비스를 사용할 수 있도록 서비스에 반영하는 것으로 구분) 

지속적 개발의 직접적인 결과는 소프트웨어의 성장에 있습니다. 현재 페이스북의 프론트엔드 코드베이스는 천만라인이 넘어가고 (실제코드로 코멘트와 공백 제외) 그중에서 PHP가 8백5십만 라인 정도가 됩니다. 아래 페이스북의 코드베이스증가율을 살펴보면, 코드베이스 규모가 해마다가파르게 성장하는 것을 볼 수 있습니다. 소프트웨어의 크기와 복잡도가 증가하면 성장율이 둔화된다는 Brooks’s Law에 속하지 않는 모습니다. 

                                                            [페이스북 개발 성장율]

지속적 배포(Continuous Deployment)를 통해 페이스북은 어제 밤에 아이디어를 얻고 오늘 아침에 코딩하고 오후에 서비스에 반영하여 데이타를 내일 얻는 것이 가능합니다. 일반 개발 회사에서 일년동안 얻을 경험을 페이스북에서는 몇 주만에 얻을 수 있다는 얘기입니다. 또한 지속적 배포는 A/B 테스팅을 통해서 라이브 실험을 수행합니다. 두 사용자 그룹에서 새로운 기능을 보여주고 사용자 행동의 변화를 비교할 수 있도록 만들어 줍니다. 이를 통해 엔지니어들은 어떤 것이 먹히고 버려야할지를 즉시 확인해 볼 수 있습니다. 


지속적 배포는 제품관점에서도 잦은 배포를 통해 신규 코드의 량이 제한됨으로써 위험을 줄이고 결함수정을 용이하게 만들어 주는 효과가 있습니다. 페이스북에 신규입사자들은 6주간의 부트캠프을 통해 실서비스에 코드를 커밋을 가능한 빨리하도록 독려하는데, 2주차에 가장 많은 코드가 커밋되는 것을 볼 수 있습니다. 

                                                      [페이스북 부트캠프에서의 첫번째 코드커밋 분포]

빠른 배포가 코드베이스에 큰 변화를 초래하는 기능 개발과는 어울릴 것 같지 않지만, 큰 기능 개발이라는 것도 작고 안전한 절차로 구분하여 쪼개면 가능합니다. 또한 페이스북은 Gatekeeper를 통해서 사용자가 보게되는 코드의 기능들 통제함으로써 개발자가 신규 기능을 최종 사용자에게 바로 노출시키지 않고 배포를 점진적으로 증가시킬 수 있도록 만들어 줍니다. (dark release로 config flag를 통해 작은 규모의 사용자에게 신규기능을 노출하여 검증하고 릴리즈 확장)

모든 페이스북 프론트엔드 개발자는 단일 코드베이스에서 작업을 합니다. 따라서 코드를 따로 브랜치했다가 트렁크(trunk)에 모아 통합하는 수고를 하지 않아 빠른 개발이 가능해집니다. 이에 따른 장단점이 있겠지만 이런 대규모 코드베이스를 하나로 가져간다는 것은 비지니스 특성과 엄격한 엔지니어링 기반이 뒷받침되지 않으면 어렵겠죠. 지속적 배포에서는 통합의 비용과 복잡함을 증가시키는 코드브랜치보다는, UI 레이어에서 config를 통해 신규 기능을 온/오프시키는 feature toggles이나 아키텍처에서의 변경이 필요하면 branch by abstraction를 통해 기존과 새로운 버전의 앱이나 서비스를 멀티로 운영하여 해결하도록 합니다. 페이스북 개발자는 깃(Git)을 통해 자신의 개발코드를 로컬에서 관리하고, 릴리즈할 안정적 코드는 서브버전(subversion)의 중앙 리파지토리에 커밋하게 됩니다. 

페이스북 엔지니어들은 주당 평균 2~3회 정도 커밋을 하는데 커밋 간격은 몇 시간 이내입니다. 커밋 성공율은 횟수가 늘어남에 따라 극격하게 줄어들며 주 10회 이상 커밋을 하는 엔지니어는 거의 없습니다. 최적의 배포 사이클은 배포 비용, 에러 발생 확률과 처리비용, 점진적 효익의 가치, 엔지니어의 기술과 문화 등 고려할 사항들이 많으며 페이스북와 같이 개인사생활을 다루는 경우 침해 우려도 있어 일간, 주간 배포를 섞어서 사용하고 있습니다. 

                                                  [페이스북 코 드커밋 주기]

2. Pushing New Features 
 
푸시 프로세스는 혁신 수준을 어느 통제 수준에서 가져갈 것인 균형을 잡아야 합니다. 신규 소프트웨어 배포의 확장은 보다 많은 엔지니어, 보다 많은 코드, 보다 많은 사용자라는 관점에서 고려할 위험들이 많습니다. 위험을 없애는 것은 불가능하기 때문에 감시 기능을 중요한 부문에 보다 집중하게 되고 일간 및 주간 푸시에 따라서도 달라집니다. 주간 푸시는 기본이 되고 수천가지 변경사항을 포함하므로 일요일 오후에 서브버전 중앙 리파지토리에 코드들이 모여 릴리즈 엔지니어가 진행합니다. 수만개의 회귀테스트 (결함과 성능)를 포함하는 자동화 테스트를 거치고나면 최신 빌드의 일부에 포함되고 페이스북 직원들이 먼저 사용하고 이후 푸시는 화요일 오후에 이루어집니다. 

릴리즈 엔지니어는 이전 성과에 기반하여 push karma로 엔지니어를 지명하는데 엔지니어가 나쁜 업보(문제를 자주 야기시키는 경향)를 갖고 있으면 푸시에 포함되기 전에 보다 엄격한 감독을 받게 됩니다. 코드 리뷰 과정에서 토론된 내용이나 코드 변화의 규모에 따라서도 얼마나 검토가 이루어질지 고려됩니다. 

릴리즈 엔지니어는 작은 주기의 푸시를 하루 2번씩 수행합니다. 푸시에 포함되는 모든 코드들은 개별 단위테스트와 코드리뷰를 반드시 거져야 합니다. (버그수정이나 마이너한 UI 수정 등이 일일 푸시에서 데이타베이스 수정을 동반하는 규모가 큰 수정이나 기능 추가 등은 주간 푸시에서 이루어질 것으로 생각됩니다.) 페이스북에서 코드리뷰는 중심적 위치를 차지하고 있는데, 모든 라인은 다른 엔지니어들에 의해 반드시 검토되어야 합니다. 

Phabricator 코드 리뷰 도구 (http://phabricator.org)와 코드 테스트 자동화 도구 (사용자 인터페이스 포함) Watir (http://watir.com/)와 Selenium (https://code.google.com/p/selenium/)을 활용합니다. 아울러 페이스북을 사내에서 활발하게 사용하면서 모든 직원들이 발견하는 모든 버그들을 바로 리포트하고 있고 있습니다. 

                                                   [Phabricator 코드 리뷰 도구]

                                              [ Watir UI  테스팅 자동화 도구 ]

                                        [ Selenium 테스팅 프레임워크: Unit, UI , 통합 테스팅 지원 ]

아울러  Perflab와 같은 성능테스팅 솔루션을 활용하여 엔지니어가 단시간에 해결할 수 없는 경우 변경된 코드를 서비스에서 제거하거나 다음번 푸시로 연기시켜 엔지니어가 문제를 해결할 수 있도록 활용합니다. 엔지니어들은 작은 성능 상의 이슈라도 지속적으로 관찰하고 문제가 축적되지 않도록 해결해야 합니다. 이런 이슈들이 방치되면 급격하게 용량과 성능 문제를 야기시키기 때문입니다. 

                                                        [ Perflab 솔루션 홈페이지 ]

페이스북에서는 스테이지별 푸시가 이루어지는데, 1차는 H1의 내부 엔지니어가 사용하는 서버에서 테스트를 거친다음 
2차는 H2로 작은 사용자 그룹을 대상으로 배포하고 문제가 없으면 전체 사용자가 사용하는 H3서버로 배포가 이루어집니다. 보통 배포되는 실행 파일 사이즈가 1.5 GB에 달하기 때문에 (웹서버와 컴파일된 페이스북 어플리케이션 포함) 전세계 4군데 장소에 서버 클러스터를 두고 배포가 이루어집니다. 모든 코드와 데이타는 BitTorrent를 통해 모든 서버들에 전파되는데 대략 20분 정도가 소요됩니다. 

릴리즈 시점에 반드시 배포할 기능을 만든 개발자가 대기해야 하는데 담당 개발자가 자리를 비우면 해당 푸시에서 그사람의 코드는 제외됩니다. 아울러 Claspin과 같은 내부 모니터링 도구를 통해 배포 후 사용자들이 기능상에 문제점이 없는지를 모니터링합니다. 
 
3. Personal Responsibility

페이스북에는 대략 1,000명의 개발자와 3명의 릴리즈 엔지니어가 푸시를 관리하며 진행합니다. 엔지니어링 조직에는 QA팀 혹은 테스트팀이 별도로 존재하지 않습니다. 일반적으로 개발, QA, 운영을 구분함으로써 서로에게 책임을 떠넘기는 소프트웨어 개발회사와 달리 페이스북 엔지니어는 자신의 코드에 테스트 코드를 짜고 자동화된 회귀테스트를 통과시켜야 합니다. 개발자들이 QA와 운영까지 지원해야하는 Devops의 문화를 갖고 있습니다. 개발자는 자신의 코드가 결함없이 운영되도록 책임을 집니다. 즉, 개인이 책임을 지는 문화가 깔려 있습니다. 

                                                [페이스북 엔지니어 조직: DevOps]


페이스북에서는 소수의 개발자들이 대부분의 파일을 처리하다보니 헤비 테일 분포도를 볼 수 있습니다. 3분의 1의 소스파일을 한명의 엔지니어가 수정하고, 4분의 1정도를 2명의 개발자가 처리합니다. 7명 이상의 엔지니어가 수정하는 파일은 10% 정도에 불과하군요. 

                                                        [개발자당 파일처리 분포]

페이스북에서는 사내협업과 아울러 경쟁도 유도합니다. PHP 성능이 인프라 비용의 가장 큰 요소로 떠오르자, 엔지니어들이 3가지의 다른 솔루션을 제시했고, 각 팀마다 병행으로 개발된 솔루션 중에서 최종적으로 가장 나은 대안 (HipHop compiler: https://github.com/facebook/hhvm, 오픈소스로php를 C++로 전환시켜주고 G++로 컴파일함. JIT 컴파일 접근방법으로 런타임 성능개선됨) 선택되고 나머지는 바로 폐기되었습니다. 페이스북은 엔지니어가 스스로 주도하는 문화라서 부트캠프에서 코드베이스, 사내문화, 프로세스 등을 배우고 나면 신입직원은 자기가 일할 팀을 본인이 선택합니다. 

혁신을 위해서 구글이 개발자의 20%시간을 자신의 프로젝트에 쏟게하는 반면 페이스북은  해카톤(hackathons)을 자주 (월단위로) 개최합니다 . 하루종일 진행되는 해카톤에는 엔지니어뿐만 아니라 사내 직원들이 모두 참여할 수 있습니다. 페이스북의 Tlimeline, Chat, Video, HipHop 등이 모두 해카톤을 통해 나온 결과물들입니다. 

                                                            [페이스북 주중 커밋 분포] 
 
 페이스북 커밋분포를 보면 주중에는 화요일, 일과중에서는 3시때가 가장 높습니다. 점심 시간에도 여전히 많은 커밋이 이루어지고, 저녁 8시 이후로는 거의 커밋이 이루어지지 않습니다. 


4. 정리

페이스북의 개발과 배포 프랙티스에 대하여 몇가지로 정리해보면 다음과 같습니다. 
  • 최종적으로 잘 정의된 제품을 달성하기 위한 구체적 계획은 만들지 않는다. 
  • 모든 엔지니어는 브랜치나 머지없이 하나의 공통된 코드기반에서 작업한다. 
  • 테스팅을 책임지는 별도의 QA 조직은 없다.
  • 매일 하루 2회 신규 코드를 릴리즈한다. 
  • 엔지니어가 무엇을 할지 스스로 결정한다. 
  • 실패에 대한 잘못을 묻지 않는다. 

아래 페이스북의 개발과 배포 프로세스에서 알 수 있듯이 자신의 환경에 적합한 개발 프로세스를 최적화하고 자동화하여 사용합니다. 
  • 제품이 미리 정의되지는 않지만 빠른 속도로 반드시 지속적으로 진화하여야 한다. 
  • 엔지니어는 도메인에서 직접 경험해야하고 사용자들이 어떤 것을 좋아하는지 파악하기 위해 테스트 과정을 주도합니다. 
  • 개인적 책임에 따라 엔지니어는 자신이 개발된 코드의 품질을 책임져야 합니다. 
  • 사용자에 대한 테스팅은 범위를 정해 수행하고 가장 정확하고 빠른 피드백을 제공해야 합니다. 
  • 누구의 잘못인지 책임을 따지는 것보다 경험을 통해 배우는 것이 가장 중요하고 이롭습니다. 
                                                  [페이스북의 개발과 배포 프로세스]

페이스북 개발문화에서 매우  흥미로운 점은 개인적 책임감이 전문화 (QA, 테스트, 운영팀 구분 및 특화), 방법론, 엄격한 절차 등을 대치했다는 점입니다. 전체 시스템을 대한 책임감을 기꺼이 지려고 하는 엔지니어 조직에서 남을 비난하거나 자기보호같은 행동들을 하지 않았기 때문이죠. 

ORA-19809: limit exceeded for recovery files

When you try to connect with Oracle Database and it throws an error message ORA-19809: limit exceeded for recovery files. It means archive destination (db_recovery_file_dest) has been full.

Following error will appear in the alert log file if you try to shutdown a database or switch a log file:

ORACLE Instance flash – Archival Error
ORA-16038: log 1 sequence# 45 cannot be archived
ORA-19809: limit exceeded for recovery files

ORA-19809 limit exceeded

To resolve this issue follow below steps:

Step-1: Issue Shutdown Abort command

SQL> conn sys/sys as sysdba

Connected.

SQL> shutdown abort;

ORACLE instance shut down.

Step-2: Mount the Oracle Database

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1071333376 bytes

Fixed Size                  1388352 bytes

Variable Size             620757184 bytes

Database Buffers          444596224 bytes

Redo Buffers                4591616 bytes

Database mounted.

Step-3: Format Column Size

SQL> col name format A50

SQL> col space_limit format A10

SQL> col space_used format A10

Step-4: Check Total Size and Used Space

SQL> select  name,  (space_limit/1024/1024) ||'MB' as Space_Limit,
(space_used/1024/1024)||'MB' as Space_Used from  v$recovery_file_dest;

NAME                                               SPACE_LIMI SPACE_USED
-------------------------------------------------- ---------- ----------
C:\oraclexe\app\oracle\fast_recovery_area          10240MB    10230MB

Step-5: Increase Archive Log Destination Size or Delete Archive Log Files

If the space is full then you have two options:

Option-A) You can increase archive destination size (db_recovery_file_dest_size)

SQL> alter system set db_recovery_file_dest_size=4096m scope=both;

Or

Option-B) You can copy all the archive log files manually at some other location and delete all those archive log files using RMAN.

C:\>rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on Thu Nov 20 15:16:56 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

connected to target database: XE (DBID=2712423074)

RMAN> DELETE ARCHIVELOG ALL;

It will prompt you for Yes/No option, Type Yes and press Enter to delete all archive log files from your Hard Disk.

Note: Backup all the archive log files before issuing DELETE ARCHIVELOG ALL command.

Step-6: Open the database

SQL> alter database open;

Database altered.

SQL>

Now check your database functioning again by shutdown and startup command.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup;

ORACLE instance started.

Total System Global Area 1071333376 bytes

Fixed Size                  1388352 bytes

Variable Size             620757184 bytes

Database Buffers          444596224 bytes

Redo Buffers                4591616 bytes

Database mounted.Database opened.



출처 : http://itbloggertips.com/2013/11/fixed-ora-19809-limit-exceeded-recovery-files/

새 프로젝트 생성시 jvmargs 설정

아래 경로에 gradle.properties를 생성
  • /home/<username>/.gradle/ (Linux)
  • /Users/<username>/.gradle/ (Mac)
  • C:\Users\<username>\.gradle (Windows)

Chrome DevTools 도구 사용하기

구글에서 나온 Chrome DevTools를 사용하면 개발시간을 단축할 수 있어 많이 소개하는데 이번에 대표적인 기능을 정리하여 소개합니다.

개발자라면 Chrome Canary를 사용하십시오!

독자는 Chrome Canary를 사용하고 계십니까> 일반인들이 사용한느 버전은 안정화된 것이고 Chrome은 거의 매일 업데이트가 일어나고 있는데 이 중에서 Canary빌드를 추천하는 이유는 다음과 같습니다.

이유는 개발자를 위한 새로운 기능을 빠르게 사용해볼 수 있기 때문입니다. 릴리즈가 느린 Chrome을 사용하고 있다면 언제까지나 최신 편리한 기능의 사용해보지 못하는 개발자의 손해가 아닐련지요. 그래소 실행확인용이라면 Chrome Canary를 사용합시다.

바로가기

바로가기부터 기억해둡니다. 이유는 앞으로의 작업효율성을 높이기 위해서입니다. 다만, 엄청 많이 제공하기 때문에 편리한 단축키 몇가지를 정리해서 소개합니다.

[btn link=”https://developers.google.com/chrome-developer-tools/docs/shortcuts?hl=ko” color=”skyBlue” size=”size-m” target=”_blank”]Keyboard Shortcuts[/btn]

[?] 또는 [F1]

개발자도구의 설정 패널을 열면 다양한 도구를 설정할 수 있지만, 중요한 것은 왼쪽에 있는 [Shortcuts]입니다. 여기에 단추키가 나열되어 있어 필요할 경우에 자주 살펴봅시다.

[command][Control] + [F]

검색으로 코드내를 검색할 때 사용하며 Elements패널에서는 CSS 실렉터와 XPath에 의한 검색이 가능합니다.

[Command] + [Alt] + [F]

크로스 검색으로 개별파일에 한정하지 않고 Sources패널내 모든 파일의 텍스트를 검색합니다.

[Command][Control] + [o]

Sources패널에서 파일을 열어서 퍼지검색에도 효과가 있어 빠르게 검색할 수 있습니다.

[Control] + [Shift] + [o]

기호검색으로 js파일이 있다고 가정하고 함수명에서 CSS파일이라면 선택기에서 찾을 수 있습니다.

[Control] + [space]

스페이스바로 자동완성 목록을 표시합니다. 이는 어떤 속성인지를 확인할 때 유용합니다.

 

Workspace기능을 사용하여 JS와 CSS파일을 편집하고 바로 로컬이 저장하기

크롬에서는 Workspace라는 기능이 있는데 개발자도구에서 편집하여 그대로 로컬로 저장하거나 로컬에 저장된 파일을 다시 로드하여 사용할 수 있는 것입니다. 이와 비슷했던 것들이 DevToolsAutoSave와 같은 플러그인이었지만 지금은 Workspace로 가능합니다.

JS와 CSS를 크롬에서 약간 조작하여 그대로 로컬로 저장이 가능하기 때문에 코딩하는 수고를 덜을 수 있는 강력한 기능으로 사용해보지 않았다면 꼭 사용해보길 권장합니다.

1) 개발자 도구를 시작하고 개발자 도구의 오른쪽 하단에 있는 기어 아이콘을 클릭하여 Settings 패널을 열고 왼쪽 컬럼에 있는 [Workspace]를 클릭하여 로컬에 있는 프로젝트폴더를 [Add folder]버튼을 클릭하여추가합니다.

chrome1_

 

폴더를 추가하면 화면 상단에 [허용]을 클릭합니다.

chrome2_

 

2) 매필할 파일을 마우스 오른쪽버튼을 클릭하여 나오는 메뉴에서 [Map to File System Resource…]를 크릭하여 로컬에서 파일을 선택하여 사용합니다.

chrome3_

 

3) 위 설정이 완료할 수 있으면 개발자 도구에서 편집한 결과가 바로 로컬에 저장됩니다. 다른 편리한 기능으로 편집한 내역이 별도의 버전으로 저장되기 때문에 필요한 경우 이전 버전으로 되돌릴 수 있습니다.

저장된 기록을 보려면 마우스 오른쪽버튼을 클릭하고 [Local Modifications]을 선택합니다. 단, 되돌리기를 하면 기록이 삭제되기 때문에 주의해야 합니다.

 

CSS속성 점프기능

CSS선택기 오른쪽 상단에 해당 선택기는 소스파일의 몇번째 줄에 있는지 클릭하면 Sources패널에 커서를 선택기에 중점을 두고 있다는 것을 알 것입니다.

하지만 CSS선택기가 아닌 속성으로 이동하려면 CSS 속성에서 [Command(Control)]+클릭으로 속성쪽으로 점핑합니다. Workspace와 같이 사용하면 좀더 쉽게 할 수 있습니다.

 

Snippets 사용하기

크롬에서 코드조각(Snippets)를 사용할 수 있는데 Sources패널에서 사이드바를 열고 Snippets라는 패널에서 오른쪽 클릭으로 조각을 만들거나 삭제할 수 있습니다. 조각 선택후 [Command(Control)]+[Enter]키로도 실행할 수 있습니다.

 

Source Map 사용하기

소스맵에 대해서 브라우저 디버깅시 유용합니다. 예로 압축된 JS나 CSS파일, SASS같은 메타 언어를 사용하는 경우, 결합 및 압된 JS는 거의 가독성이 없고 CSS도 똑같은 것으로 유효성 검사는 있지만 소스파일에서 해당되는 줄을 알 수 없습니다. 또한 SASS와 같은 메타언어를 사용하는 경우, 브라우저에서 직접 확인할 수 없기 때문에 디버깅이 어렵습니다.

이런 문제를 해결해주는 것이 바로 소스맵입니다. 크롬에서 이를 이용하는 것은 Settings패너에서 2가지를 체크해두면 사용합니다.

chrome4_

 

단, 사용시 소스맵 파일 자체가 없으면 안되기 때문에 해당 파일을 생성해야 사용이 가능합니다. 이에 관련 사용방법은 아래 링크를 참조하세요.

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

실험실 기능 사용하기

아직 구현되어 있지 않지만, 약간은 앞서서 테스트해볼 수 있는 기능들이 많이 있습니다. 이런 기능은 나중에 파일럿이라는 태그가 잡혀서 기본 기능으로 구현될 수 있고 조용히 사라질 수 있습니다. 단, 기능이 없이진 경우, 더 좋은 대안이 나오기 때문에 걱정할 필요는 없습니다.

실험실 기능을 이용하려면 “chrome://flags/에서 개발자 도구 실험(Experimental Developer Tools experiments)라는 플래그를 선택하여 재시작만 하면 됩니다.

chrome5_

 

크롬을 다시 시작한 후에 settings패널에 추가된 Experiments탭을 선택해보면 다양한 기능들이 제공됩니다. 사용하고 싶은 기능들을 체크해서 테스트해봅시다.

chrome6_

 

Command Line API가 편리합니다!

독자도 콘솔을 자주 사용합니까? 일반적으로 사용하는 console.log()이외에도 다양한 API가 있습니다. 관련 레퍼런스는 링크를 참고하세요. 필자가 자주 사용하는 것들로 정리해보면 다음과 같습니다.

최근에 선택한 요소를 참조할때

Elements패널에서 마지막으로 선택한 5가지 요소를 각각 $0, $1, $2, $3, $4 5개 변수에서 참조할 수 있도록 되어 있습니다.

assert()

console.assert()는 디버깅시 유용한데 첫번째 인수가 false로 평가된 경우에만 오류가 나옵니다. 오류 메시지는 두번째 인수로 지정할 수 있습니다.

표형태로 데이터 보기

console.table()을 사용하면 깔끔한 텡블형태로 데이터를 볼 수 있습니다.

요소검사

inspect()에 인수 요소를 넣으면 Elements패널에 전달된 요소를 포커스해줍니다. 다른 방법은 콘솔에 내뿜어진 요소에 마우스 오른쪽 클릭에 Reveal in Elements Panel을 선택하는 방법이 있습니다.

XPath를 사용

XML을 사용할 때 편리한 XPath를 콘솔로 사용할 수 있습니다. $x(xpath) 형태로 선언합니다.

 

일단 이렇게 소개를 정리하였습니다. 약간은 길지만 더많은 기능들이 많습니다. 차후에 시간이 되는데로 정리해서 추가적으로 포스팅하도록 하겠습니다.

출처 : http://html5lab.kr/blog/2013/07/31/chrome-devtools-%EB%8F%84%EA%B5%AC-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0/