인생 코딩

대부분의 OS, 프로그램은 로그를 남겨 장애시 원인 분석에 이용하게 된다.

리눅스, 특히 CentOS7 에서는 rsyslog라는 로그 시스템이 다양한 로그를 남긴다.

또한 로그가 계속 쌓이면 파일 사이즈가 비대해져 디스크 공간 부족이 생길 수 있고, 파일을 열어 분석하는 작업도 쉽지 않기에, logrotate라는 프로그램이 쌓인 로그를 파일로 분할하고, 오래된 로그 파일을 삭제하는 등의 작업을 한다.

rsyslog

시스템의 다양한 로그를 남긴다

1. 로그 파일 저장 위치 : /var/log/ 디렉토리 하위에 저장

2. 주요 로그파일

3. rsyslog 운영

rsyslog 시작

# systemctl start rsyslog

rsyslog 재시작

# systemctl restart rsyslog

rsyslog 종료

# systemctl stop rsyslog

rsyslog 상태확인

# systemctl status rsyslog

logrotate (로그로테이트)

쌓인 로그를 파일로 분할하고, 오래된 로그 파일을 삭제하는 등의 작업을 하여 로그를 관리한다.

파일을 어떻게 분할할지, 어떤 주기로 로테이트 시킬지 등은 logrotate 설정에서 가능하다.

1. logrotate 설정 : /etc/logrotate.conf

2. logrotate 설정파일 보기/수정하기

아래 명령어로 설정파일을 열어보고, 수정 후 저장하면 된다.

# vi /etc/logrotate.conf

logrotate.conf 내용 예

: 매주 로테이트, 최대 4개의 과거 로그 보관, 로그 파일 사이즈가 10M 이상이 되면 로테이트, 로그파일 압축 보관하는 예이다.

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

size 10M

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
    minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

3. logrotate 실행

기본 실행

logrotate는 crond 데몬에 의해 매일 실행된다.

실행되는 파일 위치 : /etc/cron.daily/logrotate

직접 실행

설정 변경 후 바로 적용시키는 방법이다.

# logrotate -f /etc/logrotate.conf

리눅스에서 메모리 사용량을 보는 명령어들.

1. free

# free

실행 예

2. top

# top -n1 | grep Mem

실행 예

3. meminfo

# cat /proc/meminfo | grep Mem

실행 예

4. 메모리 사용량 많은 순 프로세스 보기 (상위 10개)

# ps -eo user,pid,ppid,rss,size,vsize,pmem,pcpu,time,comm --sort -rss | head -n 11

실행 예

1. 컴파일 에러

컴파일 시, invalid new-expression of abstract class type 에러가 나는 경우가 있다.

2. 원인

구현 클래스에서, 추상클래스의 함수를 모두 구현하지 않은 경우 위 에러가 난다.

3. 해결

추상클래스에 선언된 함수 중, 구현하지 않은 함수를 찾아 구현해준다.

git을 사용해서 원격 저장소를 clone 해오면, master 브랜치만 가져와지고 다른 브랜치들은 로컬로 가져와지지 않는다.

다른 브랜치들은 따로 가져와야 한다.

원격 저장소 정보 업데이트

git remote를 갱신해서 원격 브랜치들의 정보를 최신으로 업데이트 한다.

(업데이트 안하면, 새로 추가된 원격 브랜치들이 조회가 안된다.)

$ git remote update

원격 저장소 branch 확인

1. 원격 저장소의 branch 리스트 보기

$ git branch -r

2. 원격, 로컬 모든 저장소의 branch 리스트 보기

$ git branch -a

원격 저장소의 branch 가져오기

1. 로컬에 원격 저장소와 동일한 이름의 branch를 생성하며 해당 브랜치로 checkout하기

$ git checkout -t [원격 저장소의 브랜치 이름]

원격 저장소의 test라는 브랜치를 가져오고 싶은 경우, 아래처럼 하면 된다.

$ git checkout -t origin/test

2. branch 이름을 변경하며 가져오고 싶은 경우

$ git checkout -b [생성할 브랜치 이름] [원격 저장소의 브랜치 이름]

test라는 브랜치를 new_test라는 이름으로 가져오고 싶은 경우, 아래처럼 하면 된다.

$ git checkout -b new_test origin/test

SQLite는 경량 데이터베이스이다.

따라서 데이터베이스의 한계는 어디까지인지를 파악 해볼 필요성을 느끼게 된다.

테이블 설계 시 고려해야 하기 때문. 그런데 알아 보니 소규모 어플리케이션에서는 제한 모르고 써도 무방하다 싶기도 하다..

1. string이나 BLOB의 최대 길이

SQLITE_MAX_LENGTH

• 기본값 = 1 billion (1,000,000,000)
• 최대값 = 2147483647

기본값은 설정으로 낮추거나, 높일 수 있다.

(컴파일 시, 커맨드 라인 옵션으로 -DSQLITE_MAX_LENGTH=123456789 주면 변경 가능하다 함)

2. 최대 컬럼 개수 

SQLITE_MAX_COLUMN 

• 기본값 = 2000
• 최대값 = 32767

컴파일 타임에 SQLITE_MAX_COLUMN 설정을 바꿀 수 있다.

3. 최대 SQL Statement 길이

SQLITE_MAX_SQL_LENGTH 

• 기본값 = 1,000,000,000

4. Join 가능한 최대 테이블 개수

• 최대값 = 64개 테이블

5. Expression Tree의 최대 깊이(Depth)

SQLITE_MAX_EXPR_DEPTH 

• 기본값 = 1000

(값이 0이면, 제한 없음)

6. 함수의 최대 인자 수

SQLITE_MAX_FUNCTION_ARG 

• 기본값 = 100
• 최대값 = 127

7. Compound SELECT Statement에서 최대 Term 수

SQLITE_MAX_COMPOUND_SELECT

Compound SELECT Statement 란, 두개 이상의 SELECT 문이 UNION, UNION ALL, EXCEPT, or INTERSECT로 연결된 것을 말한다.

여기서 각각의 SELECT 문을 Term이라고 부른다(SQLite의 용어).

• 기본값 = 500

8. LIKE나 GLOB 패턴의 최대 길이

SQLITE_MAX_LIKE_PATTERN_LENGTH

• 기본값 = 50000

9. 단일 SQL문에서 Host Parameter의 최대 개수

SQLITE_MAX_VARIABLE_NUMBER

Host Parameter란, SQL문에서의 기호 (보통 ? 을 사용한다)를 말한다.

• 기본값 = 999 (3.32.0 버전, 2020-5-22)
• 기본값 = 32766 (3.32.0 이후 버전)

10.  Maximum Depth Of Trigger Recursion

• 기본값 = 1000 (3.7.0 버전 부터, 2009-09-11)

그 이전 버전은 trigger가 재귀적이지 않아 의미 없다 함

11. Maximum Number Of Attached Databases

SQLITE_MAX_ATTACHED 

하나의 커넥션에 연결되 수 있는 최대 데이터베이스의 개수

• 기본값 = 10
• 최대값 = 125

12. 데이터베이스 파일에서 최대 Page 수

SQLITE_MAX_PAGE_COUNT 

• 기본값 = 1073741823
• 최대값 = 4294967294

13. 테이블의 최대 행 수

• 이론상 최대값 = 2의 64승 (18446744073709551616 or about 1.8e+19)

14. 최대 데이터베이스 사이즈

• 최대값 = 281 terabytes

(최대 페이지 수가 4294967294 이고, 각 페이지의 최대 크기가 65536 bytes 라고 했을 경우)

15. Schema의 최대 테이블 개수

• 최대값 = 2147483646

참고 : https://www.sqlite.org/limits.html

성능 벤치마킹 : https://softint.eu/choosing-sqlite-as-a-database-3-3/

Git은 브랜치별로 소스를 관리하기 편하다.

개발하려는 기능을 새로운 브랜치를 만들어 작업한 후, 작업이 완료되면 master로 통합해주는 방식으로 많이 활용된다.

아래는 쉘에서 사용 가능한 브랜치 관련 git 명령어들이다.

1. 브랜치 생성

git branch 명령으로, test라는 브랜치를 만든다

$ git branch test

2. 브랜치 이동

git checkout 명령으로 test라는 브랜치로 이동한다.

$ git checkout test

3. 브랜치 이름 변경

로컬 저장소의 브랜치 이름 변경

$ git branch -m [old_branch] [new_branch]

test라는 브랜치의 이름을, new_test로 변경하는 예는 다음과 같다.

(브랜치 명령어는 브랜치만 생성하기 때문에, 작업을 하려면 checkout을 해야 한다.)

$ git branch -m test new_test
$ git checkout new_test

원격 저장소의 브랜치 이름 변경

원격 저장소의 old_branch를 삭제하고, new_branch를 push 해주면 된다. 아래의 명령어로 한번에 할 수 있다.

$ git push origin :[old_branch] [new_branch]

원격 저장소의 test라는 브랜치를 new_test라는 브랜치명으로 바꾸는 예는 다음과 같다.

$ git push origin :test new_test

4. 브랜치 합치기

두 브랜치를 합치는 방법으로는, Merge와 Rebase가 있다.

양자는 최종 결과물은 같고, 커밋 히스토리만 다르다.

Rebase 는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고,

Merge는 두 브랜치의 최종 결과만을 가지고 합친다.

브랜치 Merge

git merge 명령으로, test 브랜치를 master 브랜치에 합친다.

$ git checkout master
$ git merge test

브랜치 Rebase

rebase를 통해 test 브랜치를 master에 합치는 예는 다음과 같다.

$ git checkout test
$ git rebase master
$ git checkout master
$ git merge test

Rebase시 주의! 

이미 공개 저장소에 Push한 커밋을 Rebase 해서 다시 push 하지 마라.

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다.

따라서 이미 공개 저장소에 c1이라는 커밋을 push 해서 다른 사람이 그 커밋을 바탕으로 작업을 했는데, 해당 커밋 c1을 rebase로 다시 push 해버리면, 동료는 rebase 내용을 pull 했을 때 본인의 코드와 충돌이 일어나게 된다.

그래서인지, rebase는 로컬작업에서만 사용하라고 권장하는 사람들도 있다.

합친 브랜치 master를 원격 저장소에 push하기

$ git push origin master

5. 브랜치 삭제

merge 후 필요 없어진 브랜치는 삭제한다.

$ git branch -d [branch_name]

아래는 test라는 브랜치를 삭제하는 예이다.

$ git branch -d test

1. 문제 상황

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted 가 뜨는 경우가 있다.

2. 원인

메모리 부족으로 추정된다.

* PHP의 메모리 제한 기본값은 128MB

3. 해결

PHP 설정파일에서 메모리 제한을 수정 후(더 큰 값으로 늘림), 웹서버를 재시작 해주면 모든 PHP 파일에 적용된다.

아래는 CentOS, Apache를 사용하는 경우의 예이다.

Bash

vi /etc/php.ini

php.ini

memory_limit = 256M

Bash

systemctl restart httpd

참고

https://zetawiki.com/wiki/PHP_%EB%A9%94%EB%AA%A8%EB%A6%AC_%EB%B6%80%EC%A1%B1

1. 문제 상황

mysql 이 자꾸 죽는다거나, 시작이 안되는 경우가 있다.

2. 원인 파악

로그파일을 분석했을 때, 아래와 같은 메시지가 있다면 메모리가 부족해서 실행을 못하는 것이다.

InnoDB 버퍼 풀 사이즈가 128M (디폴트 값)로 설정되어 있는데, 이를 수용할 만한 메모리가 부족해서 할당 못하고 fail된 것.

(물리적인 메모리 사이즈 자체가 작거나, 다른 프로그램들이 많이 돌아가고 있어 여유 메모리가 부족하거나, 이유는 다양할 수 있다.)

InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
InnoDB: Completed initialization of buffer pool
InnoDB: Fatal error: cannot allocate memory for the buffer pool
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[Note] Plugin 'FEEDBACK' is disabled.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting

3. 해결책

my.cnf 파일에 innodb_buffer_pool_size 를 낮춘 설정을 추가해 주면 된다. (아래 설정 추가)

64M도 메모리 부족으로 실행 안된다면, 32M, 16M.. 사이즈를 더 낮춰서 저장 후 mysql을 실행해보면 된다.

(메모리가 작아지면 DB 성능이 낮아질 우려는 있다.)

innodb_buffer_pool_size=64M

또는, 사용되지 않는 다른 프로그램이나 데몬들을 종료하거나, 물리적 메모리를 추가해주는 등 전체 메모리를 늘려주는 것도 방법이다.