SlideShare a Scribd company logo
186│2013 기술백서 White Paper
Commit Wait Class 대기시간 감소 방안
㈜엑셈 컨설팅본부/DB컨설팅팀 박 준연
개요
Wait Class 중 Commit 카테고리에 해당하는 Wait Event 에 의한 대기현상으로 DB 시스템의
성능 저하 현상이 발생하는 것은 종종 경험할 수 있다. 그 중 대표적인 Wait Event 는 Log File
Sync 이다. 실제로 대부분의 DB 시스템의 Top 5 Wait Event 를 조사해 보면, Log File Sync 가
이에 속해 있는 경우가 대부분이다.
하지만 Log File Sync 를 포함하여 Log File Parallel Write 등의 Commit Wait Class 에 해당하
는 Wait Event 가 발생하는 것 자체가 문제가 되진 않는다.
이는, Oracle 은 Commit 이나 Rollback 명령이 요청되면 이를 LGWR 에게 요청을 전달하며,
LGWR 은 Redo Buffer 에서 가장 마지막에 기록이 이루어진 이후 시점부터 Commit 또는
Rollback 지점까지의 모든 Redo Entry 를 Redo Log File 에 기록하는 메커니즘을 가지고 있다.
따라서, 언급한 Wait Event 들은 이와 같은 과정에서 필연적으로 발생하는 Transaction 의 부가
적인 현상일 뿐 그 자체로 문제가 된다고 볼 수 없다.
다만, 해당 Wait Event 를 대기하는 시간이 과도하게 긴 경우, 예를들어 과도한 Commit 이 발
생하는 경우 등에 따라서는 이 대기시간을 감소시켜 전반적으로 DB 시스템의 최적화된 성능을
보장할 수도 있다. 이 문서는 Commit_wait , Commit_Logging 파라미터 값의 수정을 통해
Log File Sync 의 대기시간을 경감할 수 있는 방안과 이에 대한 주의 사항에 대한 정보를 알아보
는 것을 목적으로 한다.
Part 1 ORACLE │187
Commit_Wait / Commit_Logging
두 파라미터를 통해 Log File Sync 대기 시간을 감소시킬 수 있다는 것은 놀라움과 의아함을 동
시에 느낄 수 있다. 단지 파라미터의 수정을 통해 당연히 대기해야 하는 시간을 감축한다는 것은
분명 성능을 개선해야 하는 입장에서는 놀라운 일이 될 것이다.
반면, 그에 따르는 비용도 감수해야 할 것이다. 이에 대한 자세한 내용은 마지막 부분에 언급하
는 것으로 하고, 두 파라미터에 대한 설명과 수정 가능한 값들에 대한 의미를 알아보자.
Commit_Wait
Commit_Wait 파라미터는 Server Process 가 Redo Data 를 Redo Log File 에 기록을 완
료할 때까지 대기할 것인지 말것인지를 결정하는 파라미터이다.
 Wait : Wait 값은 위 파라미터의 기본값이다. 이는 LGWR 의 작업이 완료되는 순간까
지 Server Process 가 대기함을 의미한다.
 Nowait : 말그대로 Server Process 는 해당 작업에 대해 대기하지 않음을 의미한다. 이
경우, 시스템의 ACID 의 특성 중 지속성이 침해될 수 있으므로 일반적으로는 Nowait
으로 설정하는 것을 권고하지는 않는다.
 Force_Wait : Wait 설정 값과 유사한 의미를 갖는다. 다만, 시스템 레벨에서 설정한 경
우, 세션 레벨에서 이를 무시할 수 있으며, 그 반대의 경우도 가능하다. 즉, 낮은 수준
에서의 Wait 설정이라고 이해하면 된다.
Commit_Logging
Commit_Logging 파라미터는 LGWR 가 Redo Data 를 일괄로 기록할지의 여부를 결정하
는 파라미터이다.
 Immediate : 이 값이 기본 값이며, 각 Commit 마다 LGWR 가 쓰기 작업을 진행함을
의미한다.
 Batch : 이는 LGWR 가 일괄로 Redo Data 를 기록함을 의미한다. 작은 단위의
Transaction 의 경우 이 방법으로 기록하면 보다 효율적인 방법이 될 것이다.
188│2013 기술백서 White Paper
위에서 설명한 바와 같이 이 두 파라미터의 설정 값의 변경만으로도 Log File Sync 를 포함한
Commit Class 의 대기 이벤트들의 대기 시간이 획기적으로 감소할 수 있다는 가능성이 있음을
알 수 있다. 사실 이 기능이 처음 소개된 것은 10G 때부터 인데, 10G 에서는 파라미터가
Commit_Write 라는 파라미터만 존재한다.
설정 값을 Wait , Immediate 나 Nowait, Batch 등으로 설정한다. 11G 에 와서 파라미터가 위
와 같이 두 가지로 분리되어 적용할 수 있도록 변경되었다.
Parameter 값 변경에 따른 성능 테스트
DECLARE
l_dummy INTEGER;
BEGIN
FOR i IN 1..1000
LOOP
INSERT INTO t VALUES (i, rpad('*',100,'*'));
COMMIT;
SELECT count(*) INTO l_dummy FROM dual;
END LOOP;
END;
본격적으로 두 파라미터의 값의 변경에 따른 위의 PL/SQL Block 과 같이 건건이 Commit 을 수
행하는 트랜잭션의 성능차이가 어느 정도인지 테스트를 통해 알아보도록 하자.
참고 : 아래 결과는 STRACE 를 이용하여 서버 프로세스와 LGWR 의 System Call 횟수를 보여주는
것으로 별도 첨부된 Script 를 참조할 것.
WAIT / IMMEDIATE
***** Server Process *****
Part 1 ORACLE │189
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.069561 69 1005 1 semtimedop
------ ----------- ----------- --------- --------- ----------------
100.00 0.069561 1005 1 total
***** Log Writer *****
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.013919 14 1016 io_submit
------ ----------- ----------- --------- --------- ----------------
100.00 0.013919 1016 total
NOWAIT / IMMEDIATE
***** Server Process *****
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.002195 439 5 1 semtimedop
------ ----------- ----------- --------- --------- ----------------
100.00 0.002195 5 1 total
***** Log Writer *****
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.010073 10 1015 io_submit
------ ----------- ----------- --------- --------- ----------------
100.00 0.010073 1015 total
NOWAIT / BATCH
***** Server Process *****
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.002132 533 4 1 semtimedop
190│2013 기술백서 White Paper
------ ----------- ----------- --------- --------- ----------------
100.00 0.002132 4 1 total
***** Log Writer *****
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.000533 36 15 io_submit
------ ----------- ----------- --------- --------- ----------------
100.00 0.000533 15 total
두 파라미터의 값이 Default 값인 경우(Wait/Immediate), Server Process 와 LGWR 의
System Call 횟수는 Commit 횟수와 비슷한 것으로 나타났다. Nowait/Immediate 로 설정한
경우에는 Server Process 의 Call 횟수는 급감하였지만 LGWR 의 경우는 여전히 Commit 횟수
와 비슷한 수치를 유지하고 있다.
반면에 Nowait/Batch 로 설정한 경우, 두 프로세스 모두 시스템 Call 횟수가 눈에 띄게 감소한
것으로 나타났다. 이것이 원인이 되어 Log File Sync 등의 Wait Event 대기 시간이 감소하여 전
반적인 성능 향상의 결과로 나타난다.
주의 사항 및 결론
앞서 소개한 빈번한 Commit 에 의한 대기현상을 감소하는 방안은 분명 매력적인 방법이다. 하
지만 이 역시 공짜는 아니다. ACID(Atomicity, Consistency, Isolation, Durability)라는
Transaction 의 특성 중 Durability(지속성)가 위배되는 상황이 발생할 수 있기 때문이다. 파라
미터 값의 변경의 의미는 단순히 Commit 시 마다 LGWR 가 Redo Log File 에 기록하지 않고
일정량을 한 번에 기록하여 대기 시간을 감소시키려는 목적인데, 예기치 않은 Instant Failure
가 발생한다거나 DB Shutdown 상황이 발생하면 Transaction 의 완전한 복구는 사실상 불가능
하다.
Part 1 ORACLE │191
따라서, 금융 시스템과 같은 중요한 시스템에 해당 파라미터의 변경 적용은 고려사항이 아니다.
즉, DB 시스템의 성격과 업무의 특성을 고려하여 선별적인 적용이 필요함을 의미한다.
예를 들어, Data Migration 시에 세션 단위로 파라미터 변경 값을 적용하여 작업을 수행한다던
지, 빈번한 Commit 이 발생하는 특정 업무(단, Transaction 의 지속성에 큰 영향을 받지 않는
Data 에 한함.)에 선별적으로 적용하는 등의 적절한 대처가 필요하다.
상황에 따라 영리하게 적용할 수 있다면 Commit Class 에 해당하는 Wait Event 들의 대기 시간
을 감소시켜 성능을 개선할 수 있는 확실한 카드로 사용될 수 있다고 믿는다.
별도첨부 Script
Script 1. Commi.sql
SET DEFINE ON VERIFY OFF FEEDBACK OFF PAGESIZE 0 TERMOUT OFF ECHO OFF
ALTER SESSION SET commit_wait = &1;
ALTER SESSION SET commit_logging = &2;
CREATE TABLE t (n NUMBER, pad VARCHAR2(1000));
SPOOL servprc.pid
SELECT p.spid
FROM v$process p, v$session s
WHERE p.addr = s.paddr
AND s.sid = sys_context('userenv','sid');
SPOOL OFF
execute dbms_lock.sleep(2)
DECLARE
l_dummy INTEGER;
BEGIN
FOR i IN 1..1000
LOOP
INSERT INTO t VALUES (i, rpad('*',100,'*'));
COMMIT;
SELECT count(*) INTO l_dummy FROM dual;
END LOOP;
END;
/
DROP TABLE t PURGE;
EXIT
192│2013 기술백서 White Paper
Script 2. Commit.sh
#/bin/bash
user=$1
password=$2
commit_wait=$3
commit_logging=$4
lgwr_pid=`pgrep -f lgwr_$ORACLE_SID`
strace -p $lgwr_pid -c -e io_submit -o lgwr.log &
strace_pid=`pgrep -f strace`
sqlplus -s $user/$password @commit.sql $commit_wait $commit_logging &
sleep 1
strace -p `head -1 servprc.pid` -c -e semtimedop -o servprc.log
rm servprc.pid
kill -1 $strace_pid
echo
echo "***** Server Process *****"
echo
cat servprc.log
echo
echo "***** Log Writer *****"
echo
cat lgwr.log
Ad

More Related Content

What's hot (20)

MySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxMySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptx
NeoClova
 
MySQL GTID 시작하기
MySQL GTID 시작하기MySQL GTID 시작하기
MySQL GTID 시작하기
I Goo Lee
 
Logical Replication in PostgreSQL - FLOSSUK 2016
Logical Replication in PostgreSQL - FLOSSUK 2016Logical Replication in PostgreSQL - FLOSSUK 2016
Logical Replication in PostgreSQL - FLOSSUK 2016
Petr Jelinek
 
Massive service basic
Massive service basicMassive service basic
Massive service basic
DaeMyung Kang
 
How I learned to time travel, or, data pipelining and scheduling with Airflow
How I learned to time travel, or, data pipelining and scheduling with AirflowHow I learned to time travel, or, data pipelining and scheduling with Airflow
How I learned to time travel, or, data pipelining and scheduling with Airflow
PyData
 
PostgreSQL and Benchmarks
PostgreSQL and BenchmarksPostgreSQL and Benchmarks
PostgreSQL and Benchmarks
Jignesh Shah
 
All about InfluxDB.
All about InfluxDB.All about InfluxDB.
All about InfluxDB.
mitesh_sharma
 
Apache Pulsar Overview
Apache Pulsar OverviewApache Pulsar Overview
Apache Pulsar Overview
Streamlio
 
03.Ansible 소개
03.Ansible 소개03.Ansible 소개
03.Ansible 소개
Opennaru, inc.
 
RocksDB detail
RocksDB detailRocksDB detail
RocksDB detail
MIJIN AN
 
Deploying PostgreSQL on Kubernetes
Deploying PostgreSQL on KubernetesDeploying PostgreSQL on Kubernetes
Deploying PostgreSQL on Kubernetes
Jimmy Angelakos
 
MongodB Internals
MongodB InternalsMongodB Internals
MongodB Internals
Norberto Leite
 
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander ZaitsevClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
Altinity Ltd
 
Google Bigtable Paper Presentation
Google Bigtable Paper PresentationGoogle Bigtable Paper Presentation
Google Bigtable Paper Presentation
vanjakom
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
Heungsub Lee
 
Timeseries - data visualization in Grafana
Timeseries - data visualization in GrafanaTimeseries - data visualization in Grafana
Timeseries - data visualization in Grafana
OCoderFest
 
Building large scale transactional data lake using apache hudi
Building large scale transactional data lake using apache hudiBuilding large scale transactional data lake using apache hudi
Building large scale transactional data lake using apache hudi
Bill Liu
 
Database-Migration and -Upgrade with Transportable Tablespaces
Database-Migration and -Upgrade with Transportable TablespacesDatabase-Migration and -Upgrade with Transportable Tablespaces
Database-Migration and -Upgrade with Transportable Tablespaces
Markus Flechtner
 
LMAX Disruptor - High Performance Inter-Thread Messaging Library
LMAX Disruptor - High Performance Inter-Thread Messaging LibraryLMAX Disruptor - High Performance Inter-Thread Messaging Library
LMAX Disruptor - High Performance Inter-Thread Messaging Library
Sebastian Andrasoni
 
Light-weighted HDFS disaster recovery
Light-weighted HDFS disaster recoveryLight-weighted HDFS disaster recovery
Light-weighted HDFS disaster recovery
DataWorks Summit
 
MySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxMySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptx
NeoClova
 
MySQL GTID 시작하기
MySQL GTID 시작하기MySQL GTID 시작하기
MySQL GTID 시작하기
I Goo Lee
 
Logical Replication in PostgreSQL - FLOSSUK 2016
Logical Replication in PostgreSQL - FLOSSUK 2016Logical Replication in PostgreSQL - FLOSSUK 2016
Logical Replication in PostgreSQL - FLOSSUK 2016
Petr Jelinek
 
Massive service basic
Massive service basicMassive service basic
Massive service basic
DaeMyung Kang
 
How I learned to time travel, or, data pipelining and scheduling with Airflow
How I learned to time travel, or, data pipelining and scheduling with AirflowHow I learned to time travel, or, data pipelining and scheduling with Airflow
How I learned to time travel, or, data pipelining and scheduling with Airflow
PyData
 
PostgreSQL and Benchmarks
PostgreSQL and BenchmarksPostgreSQL and Benchmarks
PostgreSQL and Benchmarks
Jignesh Shah
 
Apache Pulsar Overview
Apache Pulsar OverviewApache Pulsar Overview
Apache Pulsar Overview
Streamlio
 
RocksDB detail
RocksDB detailRocksDB detail
RocksDB detail
MIJIN AN
 
Deploying PostgreSQL on Kubernetes
Deploying PostgreSQL on KubernetesDeploying PostgreSQL on Kubernetes
Deploying PostgreSQL on Kubernetes
Jimmy Angelakos
 
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander ZaitsevClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
ClickHouse in Real Life. Case Studies and Best Practices, by Alexander Zaitsev
Altinity Ltd
 
Google Bigtable Paper Presentation
Google Bigtable Paper PresentationGoogle Bigtable Paper Presentation
Google Bigtable Paper Presentation
vanjakom
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
Heungsub Lee
 
Timeseries - data visualization in Grafana
Timeseries - data visualization in GrafanaTimeseries - data visualization in Grafana
Timeseries - data visualization in Grafana
OCoderFest
 
Building large scale transactional data lake using apache hudi
Building large scale transactional data lake using apache hudiBuilding large scale transactional data lake using apache hudi
Building large scale transactional data lake using apache hudi
Bill Liu
 
Database-Migration and -Upgrade with Transportable Tablespaces
Database-Migration and -Upgrade with Transportable TablespacesDatabase-Migration and -Upgrade with Transportable Tablespaces
Database-Migration and -Upgrade with Transportable Tablespaces
Markus Flechtner
 
LMAX Disruptor - High Performance Inter-Thread Messaging Library
LMAX Disruptor - High Performance Inter-Thread Messaging LibraryLMAX Disruptor - High Performance Inter-Thread Messaging Library
LMAX Disruptor - High Performance Inter-Thread Messaging Library
Sebastian Andrasoni
 
Light-weighted HDFS disaster recovery
Light-weighted HDFS disaster recoveryLight-weighted HDFS disaster recovery
Light-weighted HDFS disaster recovery
DataWorks Summit
 

Similar to Commit Wait Class 대기시간 감소 방안_Wh oracle (20)

Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
I Goo Lee
 
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
Ji-Woong Choi
 
Python으로 채팅 구현하기
Python으로 채팅 구현하기Python으로 채팅 구현하기
Python으로 채팅 구현하기
Tae Young Lee
 
NLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracleNLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracle
엑셈
 
대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle
엑셈
 
Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법
Young D
 
웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우
IMQA
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
Anyframe Enterprise JAVA Center-cut Framework
Anyframe Enterprise JAVA Center-cut FrameworkAnyframe Enterprise JAVA Center-cut Framework
Anyframe Enterprise JAVA Center-cut Framework
Insuk (Chris) Cho
 
Oracle History #8
Oracle History #8Oracle History #8
Oracle History #8
Kyung Sang Jang
 
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
승필 박
 
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
if kakao
 
Event Storming and Implementation Workshop
Event Storming and Implementation WorkshopEvent Storming and Implementation Workshop
Event Storming and Implementation Workshop
uEngine Solutions
 
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
엑셈
 
GDGoC_KHU_GoServer_week5_신건우,김도영.pdf
GDGoC_KHU_GoServer_week5_신건우,김도영.pdfGDGoC_KHU_GoServer_week5_신건우,김도영.pdf
GDGoC_KHU_GoServer_week5_신건우,김도영.pdf
dpfls5645
 
NO PARALLEL DML
NO PARALLEL DMLNO PARALLEL DML
NO PARALLEL DML
Kyung Sang Jang
 
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracleORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
엑셈
 
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingCloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
Amazon Web Services Korea
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
Ji-Woong Choi
 
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
EXEM
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
I Goo Lee
 
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
[오픈소스컨설팅] 아파치톰캣 운영가이드 v1.3
Ji-Woong Choi
 
Python으로 채팅 구현하기
Python으로 채팅 구현하기Python으로 채팅 구현하기
Python으로 채팅 구현하기
Tae Young Lee
 
NLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracleNLJ BATCH와 부분범위 처리_Wh oracle
NLJ BATCH와 부분범위 처리_Wh oracle
엑셈
 
대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle대량의 DML 작업에 대한 성능개선방안_Wh oracle
대량의 DML 작업에 대한 성능개선방안_Wh oracle
엑셈
 
Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법Apache JMeter로 웹 성능 테스트 방법
Apache JMeter로 웹 성능 테스트 방법
Young D
 
웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우웹서버 부하테스트 실전 노하우
웹서버 부하테스트 실전 노하우
IMQA
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
YoungSu Son
 
Anyframe Enterprise JAVA Center-cut Framework
Anyframe Enterprise JAVA Center-cut FrameworkAnyframe Enterprise JAVA Center-cut Framework
Anyframe Enterprise JAVA Center-cut Framework
Insuk (Chris) Cho
 
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
분산 트랜잭션 환경에서 데이터 일관성 유지 방안 업로드용
승필 박
 
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
글로벌 게임 플랫폼에서 무정지, 무점검 서버 개발과 운영 사례
if kakao
 
Event Storming and Implementation Workshop
Event Storming and Implementation WorkshopEvent Storming and Implementation Workshop
Event Storming and Implementation Workshop
uEngine Solutions
 
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
네트웍 설정 오류로 인한 RAC 시스템 성능 저하_Maxgauge case study
엑셈
 
GDGoC_KHU_GoServer_week5_신건우,김도영.pdf
GDGoC_KHU_GoServer_week5_신건우,김도영.pdfGDGoC_KHU_GoServer_week5_신건우,김도영.pdf
GDGoC_KHU_GoServer_week5_신건우,김도영.pdf
dpfls5645
 
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracleORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
ORACLE EXADATA HCC 압축방식 이해하기_Wh oracle
엑셈
 
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 GamingCloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
CloudWatch 성능 모니터링과 신속한 대응을 위한 노하우 - 박선용 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
Amazon Web Services Korea
 
[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
Ji-Woong Choi
 
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
제 7회 엑셈 수요 세미나 자료 연구컨텐츠팀
EXEM
 
Ad

More from 엑셈 (20)

WAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apmWAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apm
엑셈
 
웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm
엑셈
 
TP-Monitor_Wh apm
TP-Monitor_Wh apmTP-Monitor_Wh apm
TP-Monitor_Wh apm
엑셈
 
TCP 연결 과정_Wh apm
TCP 연결 과정_Wh apmTCP 연결 과정_Wh apm
TCP 연결 과정_Wh apm
엑셈
 
스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm
엑셈
 
Runtime Data Areas_Wh apm
Runtime Data Areas_Wh apmRuntime Data Areas_Wh apm
Runtime Data Areas_Wh apm
엑셈
 
네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm
엑셈
 
JVM Synchronization_Wh apm
JVM Synchronization_Wh apmJVM Synchronization_Wh apm
JVM Synchronization_Wh apm
엑셈
 
IBM JVM GC_Wh apm
IBM JVM GC_Wh apmIBM JVM GC_Wh apm
IBM JVM GC_Wh apm
엑셈
 
Hotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apmHotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apm
엑셈
 
Class Loader_Wh apm
Class Loader_Wh apmClass Loader_Wh apm
Class Loader_Wh apm
엑셈
 
All about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apmAll about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apm
엑셈
 
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracleWINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
엑셈
 
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracleTABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
엑셈
 
SSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracleSSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracle
엑셈
 
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracleSQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
엑셈
 
SQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracleSQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracle
엑셈
 
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracleSQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
엑셈
 
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracleSPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
엑셈
 
Result Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracleResult Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracle
엑셈
 
WAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apmWAS의 동작과 WEB, Servlet, JSP_Wh apm
WAS의 동작과 WEB, Servlet, JSP_Wh apm
엑셈
 
웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm웹 서버의 기능 및 역할_Wh apm
웹 서버의 기능 및 역할_Wh apm
엑셈
 
TP-Monitor_Wh apm
TP-Monitor_Wh apmTP-Monitor_Wh apm
TP-Monitor_Wh apm
엑셈
 
TCP 연결 과정_Wh apm
TCP 연결 과정_Wh apmTCP 연결 과정_Wh apm
TCP 연결 과정_Wh apm
엑셈
 
스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm스위치의 분류 및 역할_Wh apm
스위치의 분류 및 역할_Wh apm
엑셈
 
Runtime Data Areas_Wh apm
Runtime Data Areas_Wh apmRuntime Data Areas_Wh apm
Runtime Data Areas_Wh apm
엑셈
 
네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm네트워크 기반 통신 및 계층 구조_Wh apm
네트워크 기반 통신 및 계층 구조_Wh apm
엑셈
 
JVM Synchronization_Wh apm
JVM Synchronization_Wh apmJVM Synchronization_Wh apm
JVM Synchronization_Wh apm
엑셈
 
IBM JVM GC_Wh apm
IBM JVM GC_Wh apmIBM JVM GC_Wh apm
IBM JVM GC_Wh apm
엑셈
 
Hotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apmHotspot JVM GC_Wh apm
Hotspot JVM GC_Wh apm
엑셈
 
Class Loader_Wh apm
Class Loader_Wh apmClass Loader_Wh apm
Class Loader_Wh apm
엑셈
 
All about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apmAll about JDBC Performance Tuning_Wh apm
All about JDBC Performance Tuning_Wh apm
엑셈
 
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracleWINDOW FUNCTION의 이해와 활용방법_Wh oracle
WINDOW FUNCTION의 이해와 활용방법_Wh oracle
엑셈
 
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracleTABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
TABLE ACCESS 패턴을 이용한 SQL 튜닝_Wh oracle
엑셈
 
SSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracleSSD 개념 및 활용_Wh oracle
SSD 개념 및 활용_Wh oracle
엑셈
 
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracleSQL Profile을 이용한 SQL Plan 변경_Wh oracle
SQL Profile을 이용한 SQL Plan 변경_Wh oracle
엑셈
 
SQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracleSQL PlAN MANAGEMENT 활용_Wh oracle
SQL PlAN MANAGEMENT 활용_Wh oracle
엑셈
 
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracleSQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
SQL 튜닝에 Dictionary View 활용하기 Part2_Wh oracle
엑셈
 
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracleSPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
SPA(SQL Performance Analyze)를 이용한 통계 정보 수집_Wh oracle
엑셈
 
Result Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracleResult Cache 동작원리 및 활용방안_Wh oracle
Result Cache 동작원리 및 활용방안_Wh oracle
엑셈
 
Ad

Commit Wait Class 대기시간 감소 방안_Wh oracle

  • 1. 186│2013 기술백서 White Paper Commit Wait Class 대기시간 감소 방안 ㈜엑셈 컨설팅본부/DB컨설팅팀 박 준연 개요 Wait Class 중 Commit 카테고리에 해당하는 Wait Event 에 의한 대기현상으로 DB 시스템의 성능 저하 현상이 발생하는 것은 종종 경험할 수 있다. 그 중 대표적인 Wait Event 는 Log File Sync 이다. 실제로 대부분의 DB 시스템의 Top 5 Wait Event 를 조사해 보면, Log File Sync 가 이에 속해 있는 경우가 대부분이다. 하지만 Log File Sync 를 포함하여 Log File Parallel Write 등의 Commit Wait Class 에 해당하 는 Wait Event 가 발생하는 것 자체가 문제가 되진 않는다. 이는, Oracle 은 Commit 이나 Rollback 명령이 요청되면 이를 LGWR 에게 요청을 전달하며, LGWR 은 Redo Buffer 에서 가장 마지막에 기록이 이루어진 이후 시점부터 Commit 또는 Rollback 지점까지의 모든 Redo Entry 를 Redo Log File 에 기록하는 메커니즘을 가지고 있다. 따라서, 언급한 Wait Event 들은 이와 같은 과정에서 필연적으로 발생하는 Transaction 의 부가 적인 현상일 뿐 그 자체로 문제가 된다고 볼 수 없다. 다만, 해당 Wait Event 를 대기하는 시간이 과도하게 긴 경우, 예를들어 과도한 Commit 이 발 생하는 경우 등에 따라서는 이 대기시간을 감소시켜 전반적으로 DB 시스템의 최적화된 성능을 보장할 수도 있다. 이 문서는 Commit_wait , Commit_Logging 파라미터 값의 수정을 통해 Log File Sync 의 대기시간을 경감할 수 있는 방안과 이에 대한 주의 사항에 대한 정보를 알아보 는 것을 목적으로 한다.
  • 2. Part 1 ORACLE │187 Commit_Wait / Commit_Logging 두 파라미터를 통해 Log File Sync 대기 시간을 감소시킬 수 있다는 것은 놀라움과 의아함을 동 시에 느낄 수 있다. 단지 파라미터의 수정을 통해 당연히 대기해야 하는 시간을 감축한다는 것은 분명 성능을 개선해야 하는 입장에서는 놀라운 일이 될 것이다. 반면, 그에 따르는 비용도 감수해야 할 것이다. 이에 대한 자세한 내용은 마지막 부분에 언급하 는 것으로 하고, 두 파라미터에 대한 설명과 수정 가능한 값들에 대한 의미를 알아보자. Commit_Wait Commit_Wait 파라미터는 Server Process 가 Redo Data 를 Redo Log File 에 기록을 완 료할 때까지 대기할 것인지 말것인지를 결정하는 파라미터이다.  Wait : Wait 값은 위 파라미터의 기본값이다. 이는 LGWR 의 작업이 완료되는 순간까 지 Server Process 가 대기함을 의미한다.  Nowait : 말그대로 Server Process 는 해당 작업에 대해 대기하지 않음을 의미한다. 이 경우, 시스템의 ACID 의 특성 중 지속성이 침해될 수 있으므로 일반적으로는 Nowait 으로 설정하는 것을 권고하지는 않는다.  Force_Wait : Wait 설정 값과 유사한 의미를 갖는다. 다만, 시스템 레벨에서 설정한 경 우, 세션 레벨에서 이를 무시할 수 있으며, 그 반대의 경우도 가능하다. 즉, 낮은 수준 에서의 Wait 설정이라고 이해하면 된다. Commit_Logging Commit_Logging 파라미터는 LGWR 가 Redo Data 를 일괄로 기록할지의 여부를 결정하 는 파라미터이다.  Immediate : 이 값이 기본 값이며, 각 Commit 마다 LGWR 가 쓰기 작업을 진행함을 의미한다.  Batch : 이는 LGWR 가 일괄로 Redo Data 를 기록함을 의미한다. 작은 단위의 Transaction 의 경우 이 방법으로 기록하면 보다 효율적인 방법이 될 것이다.
  • 3. 188│2013 기술백서 White Paper 위에서 설명한 바와 같이 이 두 파라미터의 설정 값의 변경만으로도 Log File Sync 를 포함한 Commit Class 의 대기 이벤트들의 대기 시간이 획기적으로 감소할 수 있다는 가능성이 있음을 알 수 있다. 사실 이 기능이 처음 소개된 것은 10G 때부터 인데, 10G 에서는 파라미터가 Commit_Write 라는 파라미터만 존재한다. 설정 값을 Wait , Immediate 나 Nowait, Batch 등으로 설정한다. 11G 에 와서 파라미터가 위 와 같이 두 가지로 분리되어 적용할 수 있도록 변경되었다. Parameter 값 변경에 따른 성능 테스트 DECLARE l_dummy INTEGER; BEGIN FOR i IN 1..1000 LOOP INSERT INTO t VALUES (i, rpad('*',100,'*')); COMMIT; SELECT count(*) INTO l_dummy FROM dual; END LOOP; END; 본격적으로 두 파라미터의 값의 변경에 따른 위의 PL/SQL Block 과 같이 건건이 Commit 을 수 행하는 트랜잭션의 성능차이가 어느 정도인지 테스트를 통해 알아보도록 하자. 참고 : 아래 결과는 STRACE 를 이용하여 서버 프로세스와 LGWR 의 System Call 횟수를 보여주는 것으로 별도 첨부된 Script 를 참조할 것. WAIT / IMMEDIATE ***** Server Process *****
  • 4. Part 1 ORACLE │189 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.069561 69 1005 1 semtimedop ------ ----------- ----------- --------- --------- ---------------- 100.00 0.069561 1005 1 total ***** Log Writer ***** % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.013919 14 1016 io_submit ------ ----------- ----------- --------- --------- ---------------- 100.00 0.013919 1016 total NOWAIT / IMMEDIATE ***** Server Process ***** % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002195 439 5 1 semtimedop ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002195 5 1 total ***** Log Writer ***** % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.010073 10 1015 io_submit ------ ----------- ----------- --------- --------- ---------------- 100.00 0.010073 1015 total NOWAIT / BATCH ***** Server Process ***** % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002132 533 4 1 semtimedop
  • 5. 190│2013 기술백서 White Paper ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002132 4 1 total ***** Log Writer ***** % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000533 36 15 io_submit ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000533 15 total 두 파라미터의 값이 Default 값인 경우(Wait/Immediate), Server Process 와 LGWR 의 System Call 횟수는 Commit 횟수와 비슷한 것으로 나타났다. Nowait/Immediate 로 설정한 경우에는 Server Process 의 Call 횟수는 급감하였지만 LGWR 의 경우는 여전히 Commit 횟수 와 비슷한 수치를 유지하고 있다. 반면에 Nowait/Batch 로 설정한 경우, 두 프로세스 모두 시스템 Call 횟수가 눈에 띄게 감소한 것으로 나타났다. 이것이 원인이 되어 Log File Sync 등의 Wait Event 대기 시간이 감소하여 전 반적인 성능 향상의 결과로 나타난다. 주의 사항 및 결론 앞서 소개한 빈번한 Commit 에 의한 대기현상을 감소하는 방안은 분명 매력적인 방법이다. 하 지만 이 역시 공짜는 아니다. ACID(Atomicity, Consistency, Isolation, Durability)라는 Transaction 의 특성 중 Durability(지속성)가 위배되는 상황이 발생할 수 있기 때문이다. 파라 미터 값의 변경의 의미는 단순히 Commit 시 마다 LGWR 가 Redo Log File 에 기록하지 않고 일정량을 한 번에 기록하여 대기 시간을 감소시키려는 목적인데, 예기치 않은 Instant Failure 가 발생한다거나 DB Shutdown 상황이 발생하면 Transaction 의 완전한 복구는 사실상 불가능 하다.
  • 6. Part 1 ORACLE │191 따라서, 금융 시스템과 같은 중요한 시스템에 해당 파라미터의 변경 적용은 고려사항이 아니다. 즉, DB 시스템의 성격과 업무의 특성을 고려하여 선별적인 적용이 필요함을 의미한다. 예를 들어, Data Migration 시에 세션 단위로 파라미터 변경 값을 적용하여 작업을 수행한다던 지, 빈번한 Commit 이 발생하는 특정 업무(단, Transaction 의 지속성에 큰 영향을 받지 않는 Data 에 한함.)에 선별적으로 적용하는 등의 적절한 대처가 필요하다. 상황에 따라 영리하게 적용할 수 있다면 Commit Class 에 해당하는 Wait Event 들의 대기 시간 을 감소시켜 성능을 개선할 수 있는 확실한 카드로 사용될 수 있다고 믿는다. 별도첨부 Script Script 1. Commi.sql SET DEFINE ON VERIFY OFF FEEDBACK OFF PAGESIZE 0 TERMOUT OFF ECHO OFF ALTER SESSION SET commit_wait = &1; ALTER SESSION SET commit_logging = &2; CREATE TABLE t (n NUMBER, pad VARCHAR2(1000)); SPOOL servprc.pid SELECT p.spid FROM v$process p, v$session s WHERE p.addr = s.paddr AND s.sid = sys_context('userenv','sid'); SPOOL OFF execute dbms_lock.sleep(2) DECLARE l_dummy INTEGER; BEGIN FOR i IN 1..1000 LOOP INSERT INTO t VALUES (i, rpad('*',100,'*')); COMMIT; SELECT count(*) INTO l_dummy FROM dual; END LOOP; END; / DROP TABLE t PURGE; EXIT
  • 7. 192│2013 기술백서 White Paper Script 2. Commit.sh #/bin/bash user=$1 password=$2 commit_wait=$3 commit_logging=$4 lgwr_pid=`pgrep -f lgwr_$ORACLE_SID` strace -p $lgwr_pid -c -e io_submit -o lgwr.log & strace_pid=`pgrep -f strace` sqlplus -s $user/$password @commit.sql $commit_wait $commit_logging & sleep 1 strace -p `head -1 servprc.pid` -c -e semtimedop -o servprc.log rm servprc.pid kill -1 $strace_pid echo echo "***** Server Process *****" echo cat servprc.log echo echo "***** Log Writer *****" echo cat lgwr.log
  翻译: