Posts (page 2)
top (CPU 프로세스 상황 보여주기)
top 시스템의 프로세스 수가 얼마이고 몇 개의 프로세스가 돌아가고 있고 어떤 사용자와 데몬들이 있는지, CPU 상태는 어떤지 등에 대한 정보를 실시간으로 보여준다.
| space | 변환된 값을 보여준다. |
| ^L | 화면을 clear한 후에 새로 출력 |
| f | 출력된 정보를 추가적으로 더 선택한다 |
| h / ? | top 에서 사용할 수 있는 명령어와 그에 대한 설명을 출력 |
| k | 지정한 프로세스에 시그널을 보내 프로세스를 끝낼 수 있게 한다. |
| l | 평균 시스템 부하를 보여주는 기능으로 전환 |
| m | 메모리 정보를 보여주는 기능으로 전환 |
| n / # | 보여주는 프로세스의 개수를 지정 |
| q | top을 종료 |
| r | 지정한 프로세스의 nice값을 재조정 |
| s | 몇 초마다 정보를 갱신할 것인지 결정한다. |
| t | 합계 정보를 보여주는 기능으로 전환 |
| k | 지정한 프로세스에 시그널을 보내 프로세스를 끝낼 수 있게 한다. |
| C | 명령어의 전체 경로를 보여주는 기능으로 전환 |
| I | 유휴 프로세스 (idle process)를 보여주는 기능으로 전환 |
| P | CPU 사용률에 따라 정렬 |
| M | 상주 메모리 (resident memory)에 따라 정렬 |
| S | 실행이 끝난 프로세스의 CPU 시간까지 포함하여 프로세스가 점유한 총 CPU 시간을 표시 |
| T | 현재 CPU 타임 대 누적 CPU 타임 비율로 정렬 |
| W | 현재 설정을 ~/.toprc 파일에 저장하여 다음 번 실행할 때 현재 설정된 대로 실행되게 함 |
좀비 프로세스(Zombie process)의 정의
실행이 종료되었지만 아직 삭제되지 않은 프로세스를 말한다.
process는 죽었는데 자원을 차지하고 있는 것(전염성이 있음).
좀비프로세스는 시스템에 좋지 않은영향을 줌과 동시에, 심리적인 타격을 줌으로 좀비프로세스는 생기지 않도록 하는게 중요하다.
좀비 프로세스(Zombie process)의 발생원인
좀비프로세스가 발생하는 상황은 자식프로세스가 종료되었는데, 아직 부모프로세스가 종료되지 않았거나, 부모프로세스가 wait()계열 함수를 호출해서 자식프로세스를 정리하지 않았을 경우 발생한다.
좀비 프로세스(Zombie process)의 처리
보통 특정 프로세스를 종료시키기 위해서 우리는 kill 시스템명령어를 이용해서 해당 프로세스의 PID로 시그널을 보내며, 프로세스가 시그널에 반응하지 않을경우 -9 (SIGKILL)을 보내서 강제적으로 종료한다.
그러나 좀비프로세스의 경우 이러한 시그널을 보낸다고 하더라도 종료되지 않는다.
좀비프로세스는 실제 존재하지 않는 이미 종료된 프로세스임으로 종료된 프로세스에 종료시그널을 보낸다고 해서 여기에 반응하지는 않는다.
좀비프로세스를 막는 일반적인 방법으로는 wait()함수를 부모에서 호출하는 것이다.
wait 함수는 자식프로세스가 종료될때까지 현재 프로세스를 블럭킹 시키며, 자식이 종료되거나 시그널(주로 SIGCHLD)이 발생해서 시그널핸들러를 호출할때 return 된다.
만일 wait 를 호출하기 전에 자식프로세스가 이미 종료 되어서 좀비상태로 기다리고 있다면, 함수는 즉시 리턴한다. 리턴하면서 함수는 프로세스의 상태값을 얻어오고, task 구조체에서 해당 프로세스의 정보를 완전히 삭제한다.
wait 함수의 사용방법은?
…
/usr/bin/wget -q http://www.ABC.com/index.php -O/home/temp_directory/www/tmp_index.htm
find /home/temp_directory/www -name ‘tmp_index.htm’ -not -size 0 -exec cp {} /home/temp_directory/www/index.htm \;
cron에 걸어서 http://www.ABC.com/index.php를 1초에 한번씩 복사(copy)해 둔다.
http://www.ABC.com/index.php의 접속시
/home/temp_directory/www/tmp_index.htm의 파일이 열리도록 연결해 준다.
페이징 가는 페이지일 때의 처리문제는? (모두 copy해 두는가????)
결국 공지사항등 단일 페이지에 적합….
[참고 : MySql Bug “Calling MySQL5 stored procedures multiple times from PHP5″ ]
PHP 5와 MySQL 5를 연동하여 사용하는 조건에서 procedures를 호출(call)/query하는 도중 db접속을 까먹는 현상.
- 오랫동안 db에 접근이 없다 Query를 하면 “Lost connection to MySQL server during query”같은 에러가 뜬다?
한번 Lost Connection이 뜨고 난뒤에 다시한번 Query하면 다시 정상 작동? - Mysqli Bug?
일반 Select 구문은 여러번 실행해도 별 문제 없지만, procedure 호출을 위한 call 한번만해도 connection이 그냥 끊겨 버립니다.
[해결방안 또는 필요 사항]
- PDO 사용.
- 하나의 procedures 종료 후 다시 DB를 connect.
(이때 procedures는 insert, update, select등의 연속 작업을 피하고 하나의 작업만 해야 한다) - 하나의 procedures에서 모든 값을 처리 후 MYSQL_MULTI_QUERY로 해결.
PDO 란 무엇인가?
…
MYSQL_MULTI_QUERY란 무엇인가?
…
Popularity seems to be not absolute at least in Web2.0.
I think that that's the reason is different member system rather than it's relative conception.
View Popurls.com or Popular Buzz Today!(daybox.net).
Popular post in mixx.com is not in digg.com, and almost the whole is not same.
User have a different standard about some url or article, but that is attributed to different member system.
Digg.com want to have more user, and Mixx.com too.
if value in web2.0 is how many have user, popularity will be different.
After all, key point is where exist.
I have a Mac pc, but how to do this on a mac?
Because i had worked on window pc(Hp notebook pc) everyday, i've got a lot of hard work on Mac pc.
After meet by chance this video, i'm following that but it was tough...
If you are first on Mac pc, visit this page ([Topic : mac] "How to do this on a mac").
DB type이 MyISAM Type이면 insert, update등을 할때마다 LOCK이 발생.
myisam의 경우 insert, update시 자동 lock이 되므로 select되는 부분만 read lock을 걸어줘도 충분.
(데이터 무결성이 정확히 보장되어야 한다면 “스토리지 엔진을 InnorDB를 쓰고 트랜잭션을 사용”도 참고)
mysql의 기본 테이블 타입인 myisam의 table 단위의 lock과,
oracle, ms-sql의 row 단위 lock의 장단점.
- table단위 lock은 쓰기작업시 table 전체를 잠그기 때문에
다른사람이 그 table에 접근하기 위해 대기를 해야하는것. - row단위 lock은 해당 row를 제외한 다른 row 들도 쓰기, 읽기가 가능.
- row단위의 lock은 table단위 lock보다 어떤 row가 어떤 락 상태인지 파악하므로
리소스를 더 쓸 수 있으며, 그에따른 오버헤드도 발생할 수 있다.
기본적인 Lock의 개념
- Lock설정은 특정 Table을 사용하고 있는 상황에서 다른 접속자의 접근 차단하는 기능을 한다.
- Read Lock을 걸면 다른 사용자는 해당 Table에 읽기만 할 수 있다.
- Write Lock을 걸면 다른 사용자는 Table에 전혀 접근 할 수 없다.
LOCK TABLES tab_name READ
현재 client 이외의 client들은 tab_name이란 테이블에 READ를 못한다는 즉, SELECT를 못한다는 것.
LOCK TABLES tab_name WRITE
현재 client 만이 WRITE 즉, INSERT, DELETE 등을 할 수 있다는 것.
WRITE Lock을 걸면, 자동으로 READ lock 까지 걸린다.
Example
lock tables AAA write;
insert …
unlock tables;
User가 INSERT, DELETE, UDATE, SELECT .. FROM .. FOR UPDATE OF 문장을 실행하면, ROW LOCK (TX) TABLE LOCK (TM) RS : ROW SHARE LOCK SELECT .. FROM .. WHERE .. FOR UPDATE OF .. ; 이나 단, SELECT .. FROM FOR UPDATE OF 명령에 의해 WHERE 조건에 걸린 ROW 에 대해서는 SELECT .. FOR UPDATE OF; 문장은 테이블에는 RS LOCK 이므로 에러는 안나지만, RX : ROW EXCLUSIVE LOCK UPDATE ..;, INSERT INTO ..;, DELETE FROM ..; 이나 S : SHARE LOCK LOCK .. IN SHARE MODE; 에 의해 테이블에 생긴 LOCK 이다. SRX : SHARE ROW EXCLUSIVE LOCK TABLE .. IN SHARE ROW EXCLUSIVE MODE; 에 의해 테이블에 생긴 LOCK 이다. X : EXCLUSIVE LOCK TABLE .. IN EXCLUSIVE MODE; 에 의해 테이블에 생긴 LOCK 이다.
변경되는 ROW에 대한 ROW LOCK과 TABLE에 대한 TABLE LOCK이 발생.
INSERT INTO … VALUE.. ;,
DELETE FROM …WHERE …;,
UPDATE ..SET ..WHERE ..;,
SELECT .. FROM .. WHERE .. FOR UPDATE OF.. ; 등의 SQL 문장에서,
WHERE 조건에 해당되는 ROW에 대하여 다른 유저들이 변경할 수 없도록 EXCLUSIVE LOCK 이 생긴다.
TX LOCK이 걸린 ROW는 DML 문장을 실행한 유저가 COMMIT이나 ROLLBACK을 할때 까지 걸리므로
다른 유저들이 변경할 수 없다.
TX LOCK이 걸린 ROW가 저장된 TABLE에 대한 LOCK 이다.
DML SQL 문장을 수행하는 중에,
해당 테이블이 ALTER 나 DROP 되는 것을 방지하기 위해서 TM LOCK을 사용한다.
같은 테이블에서 실행할 수 있는 SQL 문장과 실행할 수 없는 SQL 문장을 구분하기 위해서다.
TM LOCK에는 RS(ROW SHARE), RX(ROW EXCLUSIVE), S(SHARE), SRX(SHARE ROW EXCLUSIVE), X(EXCLUSIVE) 가 있다.
table에 lock을 걸려는 transaction이 table안에 lock된 row가 있고
그 row를 변경시키고자 하는 것을 가리킨다.
LOCK TABLE .. IN ROW SHARE MODE; 명령에 의해 해당 테이블에는 RS LOCK 이 생긴다.
RS LOCK 이 걸린 테이블에는 RS, RX, S, SRX LOCK 을 걸 수 있고, X LOCK 은 걸 수 없다.
TX LOCK 이 생기므로 이 ROW 에 대해서 UPDATE, DELETE 를 실행할때는 테이블에 대해서는
RX LOCK이 생기므로 에러는 안 나지만, COMMIT 이나 ROLLBACK 할때까지 WAITING 을 한다.
ROW 에 대해서는 TX LOCK 이 걸리므로 WAITING 한다.
lock이 걸린transaction이 그 table에 있는 row들에 대해
하나 이상의 update를 수행하고자 하는 것을 가리킨다.
LOCK .. IN ROW EXCLUSIVE MODE ; 명령에 의해 테이블에 걸리는 LOCK 이다.
RX LOCK 도 RS LOCK 과 비슷한 내용이고, 단지 S, SRX, X LOCK 을 걸 수 없다.
Transaction에 의해서 걸리는 share table lock은 다른 transaction들이
단지, table에 대한 query, SELECT … FOR UPDATE를 이용한 특정 row에 대한
lock, LOCK TABLE … IN SHARE MODE문들을 성공적으로 수행하기 위해서 허용한다.
S LOCK 은 같은 테이블에 대해서 RS, S LOCK 만 가능하고, RX, SRX, X LOCK 을 걸 수는 없다.
SQL> LOCK TABLE EMP IN SHARE MODE;
한 시점에 주어진 table에 대해 하나의 share row exclusive table lock만이 걸릴 수 있다.
transaction에 의해 걸린 share row exclusive table lock은
다른 transaction이 query을 하거나 SELECT … FOR UPDATE로
특정 row를 lock하는 것을 허용하나 table의 갱신은 허용하지 않는다.
SRX LOCK 은 같은 테이블에 대해서 RS LOCK 만 가능하고 RX, SRX, S, X, LOCK 을 걸 수 없다.
SQL> LOCK TABLE 사원 IN SHARE ROW EXCLUSIVE MODE;
lock을 건 transaction이 table에 대한 access를 exclusive write로 허용하는
table lock의 가장 제한적인모드
X LOCK 은 같은 테이블에서는 어떠한 LOCK 도 걸 수 없다.
즉, DROP TABLE ..;, ALTER TABLE ..; 등의 DDL 문장에 의해 테이블에 생기는 LOCK 이다.