데이터베이스는 대규모 캐시입니다. 디스크 및 파일 시스템
나는 다소 심각한 부하가 있는 프로젝트에서 데이터베이스가 메모리에 맞거나 작동하지 않는다는 사실에 대해 글을 쓰겠다고 약속했습니다. 현대 세계의 상황은 SSD 드라이브의 출현으로 변화하고 있지만 현재로서는 기존의 회전식 드라이브에 비해 상당히 비쌉니다. 손으로 '만져보기' 위해 간단한 테스트를 해보겠습니다.
t1.micro 크기의 Amazon 클라우드 호스팅에서 Ubuntu 12.04를 사용하여 새 시스템을 시작했습니다. 그런 다음 postgresql-contrib-9.1 및 Ruby라는 2개의 패키지를 설치해야 합니다.
PostgreSQL contrib에는 무엇보다도 PostgreSQL 부하 테스트를 위해 특별히 설계된 pgbench 프로그램이 포함되어 있습니다.
postgresql.conf에서 shared_buffers 매개변수는 64MB로 설정되었습니다.
파일. 열기 ("res.txt" , "w" ) do | 에프 | (1 .. 50 ). 각각 | 초 | # -i는 깨끗한 데이터베이스를 생성한다는 의미입니다. # -s는 배율 인수로, 데이터베이스 크기를 결정합니다. `/usr/lib/postgresql/9.1/bin/pgbench -i -s#(들)` # -S - 읽기 전용 요청 테스트 # -T 20 - 테스트는 20초 동안 지속됩니다.# -c 40 - 40개 클라이언트 # -j 4 - 4개 스레드 res = `/usr/lib/postgresql/9.1/bin/pgbench -c 40 -j 4 -S -T 20` res f 를 넣습니다. res end end 쓰기
t1.micro 시스템에서 free -m은 다음을 제공합니다: 캐시된 사용된 총 사용 가능한 공유 버퍼 Mem: 590 583 6 0 1 428
이것이 스케일 팩터 경계의 선택을 결정하는 것입니다. scalefactor = 50에 대해 데이터베이스의 크기는 약 750MB, 즉 사용 가능한 메모리 양보다 많으며, shared_buffers 경계는 scalefactor 값 4-5에서 교차됩니다.
그래프를 살펴보겠습니다.
데이터는 그다지 아름답지는 않았지만 일반적으로 이해할 수 있었습니다. 스케일 팩터 5 영역에서 하락을 볼 수 있고 스케일 팩터 45 영역에서 다음 하락을 볼 수 있습니다. 실제로 공유 버퍼에서 벗어나 디스크 캐시에서 벗어나는 두 가지 분명한 단계가 있습니다.
2015년 2월 16일
PostgreSQL 성능 최적화
관리자별
구성 설정
리소스 설정
공유_버퍼
활성 작업을 수행하는 데 필요한 PostgreSQL 프로세스 간에 공유되는 메모리 양입니다. PostgreSQL도 디스크 캐시를 사용하므로 크기를 너무 크게 지정하면 안 됩니다.
값:
- 평균 데이터 볼륨 및 256-512MB의 사용 가능한 메모리: 16-32MB
-
대용량 데이터 및 1~4GB의 사용 가능한 메모리: 64-256MB
임시_버퍼
주로 임시 테이블을 위한 임시 개체용 버퍼입니다.
순서를 정할 수 있어요 16MB
max_prepared_transactions
동시에 준비된 트랜잭션 수입니다.
1C 작업의 경우 이 매개변수는 의미가 없습니다. PREPARE TRANSACTION은 사용되지 않습니다.
기본값으로 둘 수 있음 - 5
work_mem
단일 쿼리에 대한 테이블 정렬 및 캐싱에 사용되는 특수 메모리입니다.
이 매개변수를 설정할 때 한 번에 실행되는 동시 요청 수를 고려해야 합니다.
1~4Gb 메모리의 경우 32~128MB 설치를 권장합니다.
Maintenance_work_mem
VACUUM, CREATE INDEX, ALTER TABLE 및 FOREGIN KEY 작업에 사용되는 메모리입니다.
work_mem보다 높은 값으로 설정해야 합니다. 값이 너무 크면 스왑이 사용됩니다.
1-4Gb 메모리의 경우 128-512MB 설치를 권장합니다.
최대_스택_깊이
서버용 특수 스택으로, 이상적으로는 OS 커널에 설정된 스택 크기와 일치해야 합니다. 커널보다 높은 값으로 설정하면 오류가 발생할 수 있습니다.
2~4MB 설치를 권장합니다.
max_fsm_relations
전체 여유 공간 맵에서 여유 공간이 추적되는 최대 테이블 수입니다. 이 데이터는 VACUUM에 의해 수집됩니다.
데이터베이스의 테이블 수에 따라 여백을 두고 매개변수를 설정하십시오. (8.4 버전까지 적용 가능)
max_fsm_pages
여유 공간 정보를 저장할 블록 수입니다. 정보는 공유 메모리에 저장되며 각 레코드에는 6바이트가 필요합니다.
이 매개변수를 사용하면 베이스에 VACUUM FULL을 사용하지 않아도 됩니다. (8.4 버전까지 적용 가능)
이 매개변수는 16*max_fsm_relations 이상이어야 합니다.
이 매개변수는 initdb 유틸리티를 사용하여 데이터베이스를 생성할 때 자동으로 설정됩니다.
수동으로 설정할 수도 있습니다. 시작 근사치로 VACUUM 명령 실행 사이에 수정된 평균 레코드 수(UPDATE 또는 DELETE)의 절반을 사용할 수 있습니다.
다음을 실행하여 이 값을 추정할 수 있습니다(데이터베이스는 한동안 작동했어야 함).
진공 전체 분석;
알림: 필요한 페이지 슬롯 수(196272)가 max_fsm_pages(153600)를 초과합니다.
힌트: 구성 매개변수 "max_fsm_pages"를 196272 이상의 값으로 늘리는 것을 고려하십시오.
max_files_per_process
프로세스 및 해당 하위 프로세스가 한 번에 열 수 있는 최대 파일 수입니다.
"라는 메시지가 표시되면 이 매개변수를 줄이세요. 열린 파일이 너무 많습니다.".
디스크에 트랜잭션 로그 쓰기
commit_delay 및 commit_siblings
commit_delay 값은 마이크로초(기본적으로 0)로 표시됩니다. commit_siblings 값은 단위(기본적으로 5)로 표현됩니다.
commit_delay는 트랜잭션 로그 버퍼에 들어가는 레코드와 이를 디스크에 플러시하는 사이의 지연을 정의합니다. 트랜잭션이 성공적으로 완료되면 최소한 commit_siblings 트랜잭션이 활성화된 경우 commit_delay 기간 동안 쓰기가 지연됩니다. 이 시간 동안 다른 트랜잭션이 완료되면 해당 변경 사항은 하나의 시스템 호출을 사용하여 함께 디스크에 플러시됩니다. 이러한 매개변수는 많은 "소규모" 트랜잭션이 병렬로 수행되는 경우 작업 속도를 높여줍니다.
fsync
이 매개변수는 트랜잭션이 완료될 때 캐시에서 디스크로 데이터를 플러시하는 역할을 합니다.
그 값을 설정하면
fsync=끄기
그러면 작업이 완료된 직후 데이터가 디스크 드라이브에 기록되지 않습니다. 이를 통해 삽입 및 업데이트 작업 속도를 크게 향상시킬 수 있지만 오류가 발생하는 경우(예기치 않은 정전, OS 오류, 디스크 하위 시스템 오류) 데이터베이스가 손상될 위험이 있습니다.
배터리가 부족할 때 시스템을 종료하는 안정적인 UPS와 소프트웨어가 있는 경우에만 이 기능을 사용하십시오.
시스템 불안정으로 인해 Windows 플랫폼에서 PostgreSQL을 실행할 때 fsync를 비활성화하면 안 됩니다.
wal_sync_method
데이터를 강제로 디스크에 기록하는 데 사용되는 방법입니다.
fsync=off인 경우 이 옵션은 사용되지 않습니다.
가능한 값:
open_datasync- O_DSYNC 매개변수와 함께 open() 메소드를 사용하여 데이터 쓰기
fdatasync- 각 커밋 후에 fdatasync() 메서드 호출
fsync_writethrough- 병렬 프로세스를 무시하고 각 커밋 후에 fsync()를 호출합니다.
fsync- 각 커밋 후에 fsync()를 호출합니다.
open_sync- O_SYNC 매개변수와 함께 open() 메소드를 사용하여 데이터 쓰기
특정 플랫폼에서는 모든 방법을 사용할 수 있는 것은 아닙니다. 기본적으로 시스템에서 사용 가능한 첫 번째 항목이 설치됩니다.
full_page_writes
fsync=off인 경우 이 매개변수를 off로 설정합니다.
그렇지 않으면
이 옵션이 켜져 있으면 PostgreSQL은 체크포인트 이후 첫 번째 테이블 수정 중에 각 페이지의 내용을 트랜잭션 로그에 기록합니다. 프로세스 중에 OS가 충돌하는 경우 페이지를 부분적으로만 쓸 수 있기 때문에 이는 필요합니다. 이로 인해 새 데이터가 디스크의 이전 데이터와 혼합됩니다. 행 수준 트랜잭션 로그 항목은 충돌 후 데이터를 완전히 복원하는 데 충분하지 않을 수 있습니다. full_page_writes는 트랜잭션 로그에 기록되는 데이터를 늘리는 대신 올바른 복구를 보장합니다. (트랜잭션 로그는 항상 체크포인트에서 시작하기 때문입니다. 쓰기 볼륨을 줄이는 유일한 방법은 체크포인트 간격을 늘리는 것입니다.)
wal_buffers
트랜잭션 로그를 유지하기 위해 SHARED MEMORY에서 사용되는 메모리 양입니다.
사용 가능한 메모리가 1~4GB인 경우 256~1024kb 설치를 권장합니다.
쿼리 최적화
활성화_네스트루프
쿼리 플래너의 사용을 지정합니다. 어떤 경우에는 스케줄러를 끄면 개별 요청의 실행 시간이 상당히 줄어들 수 있습니다. 그러나 대부분의 경우 스케줄러는 쿼리 실행 시간을 줄일 수 있습니다. 적어도 영구적으로 끄면 안 됩니다.
random_page_cost
비순차적 데이터 열거의 "비용"에 대한 스케줄러의 추정치를 설정합니다. 기본값은 4.0입니다. seq_page_cost에 비해 이 값을 줄이면 스케줄러가 인덱스 스캔을 선호하게 되고 반대로 값을 늘리면 인덱스 스캔 비용이 더 높아집니다. 두 값을 모두 변경하여 디스크 I/O 작업의 "비용"과 CPU 사용의 "비용" 비율을 변경할 수 있습니다. 이는 다음 매개변수로 설명됩니다.
빠른 디스크 어레이가 있는 서버에서는 초기 설정을 3.0, 2.5 또는 2.0으로 줄이는 것이 좋습니다. 데이터베이스의 활성 부분이 RAM 크기보다 훨씬 큰 경우 매개변수 값을 높여보세요. 쿼리 성능 측면에서 최적의 값 선택에 접근할 수 있습니다. 쿼리 플래너가 필요한 것보다 더 자주 인덱스 스캔보다 순차 스캔을 선호하는 경우 값을 낮추십시오. 반대로, 스케줄러가 스캔해서는 안 되는 느린 인덱스를 스캔하도록 선택하는 경우 설정을 높이는 것이 좋습니다. 변경 후에는 가능한 가장 광범위한 쿼리 집합에서 결과를 주의 깊게 테스트하세요. random_page_cost를 2.0 이하로 낮추지 마십시오. random_page_cost를 더 낮춰야 한다고 생각한다면 이 경우 스케줄러 통계 설정을 변경하는 것이 더 합리적입니다.
CPU_tuple_cost
쿼리 실행 중 각 행을 처리하는 데 드는 "비용"에 대한 스케줄러의 추정치를 설정합니다. 기본값은 0.01입니다.
cpu_index_tuple_cost
인덱스 스캔 작업 중 각 인덱스를 처리하는 "비용"에 대한 스케줄러의 추정치를 설정합니다. 기본값 0.005
CPU_operator_cost
쿼리 실행 중 각 문이나 함수를 실행하는 데 드는 비용에 대한 스케줄러의 추정치를 설정합니다. 기본값은 0.0025입니다.
유효_캐시_크기
단일 요청에 대한 파일 캐싱을 위해 OS에서 사용하는 메모리 양에 대한 데이터를 쿼리 플래너에 보고합니다.
OS의 이 매개변수는 설정에서 볼 수 있습니다.
Windows의 경우: 작업 관리자, 성능 탭, 실제 메모리 - 시스템 캐시.
Linux의 경우: free 명령을 입력하고 캐시된 열에 필요한 값(kB)을 입력하세요.
이 값은 특정 시점의 경쟁 요청 수(데이터베이스에 대한 평균 연결 수 + 예약 수)로 나누어야 합니다.
default_statistics_target
테이블에 대한 통계의 깊이를 설정합니다. 값이 클수록 ANALYZE 명령의 실행 시간이 늘어날 수 있지만 쿼리 계획 구성이 향상됩니다.
100 정도로 설정하는 것이 좋습니다.
제약_제외
쿼리를 작성할 때 플래너의 테이블에 대한 CONSTRAINT 제약 조건 사용을 활성화하거나 비활성화합니다.
값을 on으로 설정하는 것이 좋습니다. 그러나 테이블의 CONSTRAINT를 변경하는 경우 ANALYZE를 실행하여 통계를 업데이트해야 합니다. 그렇지 않으면 잘못된 쿼리 계획이 작성됩니다.
통계수집
통계_명령어_문자열
현재 실행 중인 명령어와 명령어 실행 시작 시간에 대한 정보를 통계 수집기로 전송할지 여부입니다.
에 설정
통계_시작_수집기
통계 수집 활성화 여부.
에 설정
통계_행_수준, 통계_블록_수준
각각 레코드 및 블록 수준에서 활동 정보를 수집할지 여부입니다.
설치하다
stats_row_level=on
stats_block_level=꺼짐
stats_reset_on_server_start
서버를 다시 시작하면 통계를 재설정해야 합니까?
출발하다
자동 진공화
VACUUM - 가비지 수집. VACUUM은 "죽은" 데이터가 차지하는 공간을 복원합니다. 일반적인 데이터 작업을 수행할 때 PostgreSQL은 테이블에서 데이터를 물리적으로 제거하지 않습니다. 이는 VACUUM 작업에서 발생합니다.
자동 진공화
autovacuum(VACUUM 자동 시작)을 켤지 여부,
에 설정
autovacuum_naptime
Autovacuum 시작 사이에 일시 중지합니다.
테이블의 데이터가 업데이트되는 빈도에 따라 다릅니다. 약 5분 정도 가능하며, 기본값은 1분입니다.
autovacuum_analyze_threshold
테이블에서 ANALYZE를 트리거하는 데 필요한 최소 삽입, 업데이트 또는 삭제 수를 정의합니다. 이 설정은 저장소 설정을 변경하여 테이블별로 변경할 수 있습니다.
autovacuum_vacuum_threshold
테이블에서 VACUUM을 트리거하는 데 필요한 최소 삽입, 업데이트 또는 삭제 수를 정의합니다. 이 설정은 저장소 설정을 변경하여 테이블별로 변경할 수 있습니다.
자물쇠
max_locks_per_transaction
트랜잭션당 잠금 수:
250정도로 설정
교착 상태_시간 초과
교착상태 수명.
약 2초로 설정합니다.
가능한 오류
구성 파일을 수정한 후 PostgreSQL이 시작되지 않고 다음 오류가 발생할 수 있습니다.
치명적: 공유 메모리 세그먼트를 생성할 수 없습니다:...
실패한 시스템 호출은 shmget(key=5432001, size=140075008, 03600)입니다.
이 오류는 일반적으로 공유 메모리 세그먼트에 대한 PostgreSQL의 요청이 커널의 SHMMAX 매개변수를 초과했음을 의미합니다. 요청 크기를 줄이거나 더 큰 SHMMAX로 커널을 재구성할 수 있습니다. 요청 크기(현재 140075008바이트)를 줄이려면 PostgreSQL의 shared_buffers 매개변수(현재 16384) 및/또는 해당 max_connections 매개변수(현재 10)를 줄이세요.
요청 크기가 이미 작은 경우 커널의 SHMMIN 매개변수보다 작을 수 있으며, 이 경우 요청 크기를 늘리거나 SHMMIN을 재구성해야 합니다.
PostgreSQL 문서에는 공유 메모리 구성에 대한 자세한 정보가 포함되어 있습니다.
이 문제를 해결하려면 시스템에서 SHMMAX 매개변수를 늘려야 합니다. 다음과 같이 이 작업을 수행할 수 있습니다(Linux OS의 경우).
다음 명령을 실행하십시오.
에코 150829120 > /proc/sys/kernel/shmmax
매개변수에 대한 새 값을 지정합니다(PostgreSQL 오류 로그에서 찾을 수 있음). 이 작업은 즉시 매개변수를 설정하지만 시스템을 재부팅한 후에는 변경 사항이 손실됩니다. 이러한 일이 발생하지 않도록 하려면 /etc/sysctl.conf 파일에 다음 줄을 추가하십시오.
kernel.shmmax = 150829120
당신의 의미를 나타냅니다.
2G RAM이 있는 서버의 구성 예
중간 설정
최대 성능을 위한 중간 정적 설정입니다. 특정 사례에는 다른 설정이 더 적합할 수도 있습니다. 이 가이드를 주의 깊게 읽고 이 정보를 기반으로 PostgreSQL을 구성하십시오.
RAM - 메모리 크기
* shared_buffers = 1/8 RAM 이상(그러나 1/4 이하);
* 1/20 RAM의 work_mem;
* 1/4의 Maintenance_work_mem;
* 데이터베이스의 계획된 테이블 수에 대한 max_fsm_relations * 1.5;
* max_fsm_relations의 max_fsm_pages * 2000;
* fsync = 사실;
* wal_sync_method = fdatasync;
* commit_delay = 10 ~ 100 ;
* commit_siblings = 5~10;
* Effective_cache_size = 캐시된 값에서 0.9, 이는 무료로 표시됩니다.
* random_page_cost = 빠른 CPU의 경우 2, 느린 CPU의 경우 4;
* cpu_tuple_cost = 빠른 CPU의 경우 0.001, 느린 CPU의 경우 0.01;
* cpu_index_tuple_cost = 빠른 CPU의 경우 0.0005, 느린 CPU의 경우 0.005;
*자동 진공=켜짐
* autovacuum_vacuum_threshold = 1800
* autovacuum_analyze_threshold = 900
기지 유지보수
데이터베이스를 처음 실행하면 데이터를 입력한 후 전체 데이터베이스에 대해 ANALYZE를 수행해야 합니다.
VACUUM은 구성 파일의 설정에 따라 자동으로 수행됩니다.
autovacuum이 올바르게 구성된 경우 VACUUM FULL을 수행할 필요가 없습니다.
디스크 및 파일 시스템
서버에 여러 개의 물리적 디스크가 있는 경우 데이터베이스 파일과 트랜잭션 로그를 여러 디스크에 배포할 수 있습니다.
서버를 중지합니다.
데이터베이스 디렉터리에 위치한 pg_clog 및 pg_xlog 디렉터리를 다른 디스크로 이동합니다.
이전 위치에 심볼릭 링크를 만듭니다.
서버를 시작합니다.
어떤 DBMS(1C용 Postgresql 또는 MS SQL)가 가장 최적인지에 대한 질문이 많은 기사의 주제였습니다. 이 기사에서는 두 가지 모두에 대한 최적화 단계를 살펴보겠습니다. 각 공급업체의 DBMS에는 자체 구성 권장 사항과 1C의 권장 사항이 모두 있습니다. 장비, 서버 구성 및 다양한 부하를 설정하는 사용자 수에 따라 1C용 DBMS 최적화 및 권장 사항 구현 프로세스의 세부 사항이 변경될 수 있습니다.
1C용 PostgreSQL 설정
PostgreSQL에서 1C 데이터베이스를 운영한 경험에 따르면 1C 및 PostgreSQL의 최고 성능과 최적의 운영은 Linux에서 달성되었으므로 사용하는 것이 좋습니다. 그러나 운영 체제에 관계없이 PostgreSQL 설치 시 지정된 기본 설정은 DBMS 서버 시작에만 사용된다는 점을 기억하는 것이 중요합니다. 산업적 착취에 대해서는 말할 수 없습니다! 출시 후 다음 단계는 1C용 PostgreSQL 최적화입니다.
- 먼저 에너지 절약을 비활성화하고(그렇지 않으면 데이터베이스 응답 지연이 예측할 수 없을 정도로 증가할 수 있음) 공유 메모리 스와핑을 금지합니다.
- DBMS 서버의 기본 매개변수를 구성합니다(구성에 대한 권장 사항은 공급업체의 공식 웹사이트와 1C 모두에 충분히 자세히 설명되어 있으므로 가장 중요한 매개변수에만 집중하겠습니다).
- 1C 회사의 표준 권장 사항은 HyperThreading 메커니즘을 비활성화하는 것을 제안합니다. 그러나 SMT(동시 멀티 스레딩)가 활성화된 서버에서 Postgres-pro를 테스트하면 다른 결과가 나타났습니다.
PostgreSQL 설치
Windows에서 PostgreSQL에 1C를 설치하는 것은 매우 간단한 과정입니다. 설치 패키지를 실행할 때 UTF-8 인코딩을 지정해야 합니다. 실제로 이것은 유일하게 흥미로운 뉘앙스이며 Windows에서 1C 8.3용 PostgreSQL을 추가로 구성할 필요가 없습니다. Linux OS에서 1C용 PostgreSQL을 설치하고 구성하면 여러 가지 어려움이 발생할 수 있습니다. 이를 극복하기 위해 예를 들어 Ubuntu 16.04 x64 서버에서 PostgreSQL을 실행하는 것을 고려해 보겠습니다(러시아의 주요 공급업체인 PostgreSQL-Pro 및 1C 회사의 배포 키트 사용).
PostgreSQL DBMS용 1C 배포 키트 설치
1. PostgreSQL DBMS 배포 키트의 지정된 위치를 다운로드합니다.
2. PostgreSQL을 서버에 업로드합니다.
3. 다음 명령을 사용하여 PostgreSQL DBMS 설치 프로그램의 압축을 풀 수 있습니다.
tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz24. PostgreSQL DBMS 배포 키트를 설치하기 전에 시스템에 필요한 로케일(기본적으로 ru_RU.UTF-8)이 있는지 확인하십시오.
5. PostgreSQL이 작동하는 시스템이 러시아어가 아닌 언어로 설치된 경우 새 로케일을 생성해야 합니다.
locale-gen ru_RU 업데이트-로케일 LANG=ru_RU.UTF8 dpkg-reconfigure locales6.필요한 로케일이 여전히 사용 가능한 경우 기본적으로 설치합니다.
locale –a nano /etc/default/locale 내용을 LANG=ru_RU.UTF-8로 바꿉니다.7.재부팅 후 PostgreSQL 버전에 필요한 패키지를 설치합니다.
apt-get libxslt1.1 SSL-cert 설치8.PostgreSQL 패키지 버전 9.4.2-1.1C는 libicu 패키지 버전 libicu48에 연결됩니다. 필요한 버전은 더 이상 저장소에 없지만 다운로드할 수 있습니다.
9.다운로드한 PostgreSQL용 파일이 저장된 디렉터리에 배치합니다.
10.PostgreSQL 파일이 있는 디렉터리로 이동하여 다음 명령을 순차적으로 입력하여 설치를 수행합니다.
CD<Путь к папке с файлами>dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb11.완료. PostgreSQL DBMS 배포 패키지가 설치되었습니다.
PostgreSQL-Pro 배포판 설치
서버를 설치하려면 다음 명령을 연속해서 실행해야 합니다.
sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - http://1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get 업데이트 sudo apt-get install postgresql-pro-1c-9.4서버에 액세스하려면 파일의 매개변수를 편집하세요. pg_hba.conf
CD<Путь до каталога pg_hba.conf>cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"파일 자체의 구조는 다음과 같습니다.
파일은 잘 문서화되어 있지만 영어로 되어 있습니다. 주요 매개변수를 간단히 살펴보겠습니다.
- 현지의유닉스를 통해서만 로컬 연결
- 주인 TCP/IP 연결
- 호스트 SSL TCP/IP를 통한 암호화된 SSL 연결(서버는 SSL 지원으로 구축되어야 하며, ssl 매개변수도 설정되어야 함)
- 호스트노슬 TCP/IP를 통한 암호화되지 않은 연결
- 신뢰하다인증 없이 인정하다
- 거부하다인증 없이 거절하다
- 비밀번호일반 텍스트 비밀번호 요청
- MD5 MD5 형식의 비밀번호 요청
- LDAP LDAP 서버를 사용하여 사용자 이름과 비밀번호 확인
- 반지름 RADIUS 서버를 사용하여 사용자 이름과 비밀번호 확인
- 팸플러그인 서비스를 사용하여 사용자 이름과 비밀번호 확인
더 자세하고 자세한 정보는 PostgreSQL 제품 설명서에서 확인할 수 있습니다.
root@NODE2:/home/asd# 서비스 --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# 서비스 postgresql start root@NODE2:/home/asd# service --status-all | grep 포스트그레스 [ + ] 포스트그레SQL기본 설치를 완료한 후 PostgreSQL, 1C 서버 및 Ubuntu 서버 구성의 세부 사항에 따라 postgresql.conf 서버 구성 파일을 구성해야 합니다.
MS SQL Server에 대한 1C 최적화
SQL Server에 대한 최신 업데이트를 설치합니다.
운영 체제는 공간을 예약하고 0으로 채웁니다. 이는 다음과 같은 경우 꽤 오랜 시간이 걸립니다.
- 데이터베이스 생성;
- 기존 데이터베이스에 데이터 파일, 트랜잭션 로그 추가
- 기존 파일 크기 늘리기(자동 증가 작업 포함)
- 데이터베이스나 파일 그룹을 복원합니다.
이 문제는 로컬 보안 정책 항목 '볼륨 유지 관리 작업 수행'에 역할(서버가 실행되는 역할)을 추가하면 해결됩니다.
가능하다면 TempDB 데이터베이스(특히 RCSI 관리 잠금 모드에서 집중적으로 사용됨)와 트랜잭션 로그를 다른 디스크에 배포해야 합니다.
SQL Server를 실행하는 서버에서는 절전 모드를 "고성능"으로 설정해야 합니다.
데이터베이스 파일이 있는 폴더는 압축하면 안 됩니다.
서버의 "메모리" 탭에서 최소 수준을 전체 메모리의 50%로 설정했습니다. 다음 공식 중 하나를 사용하여 최대값을 계산합니다.
- 최대 메모리 = 총 볼륨 - OS에 따른 크기 - 1C의 크기(존재하는 경우 이전에 카운터와 함께 사용된 메모리를 측정한 경우) 또는
- 최대 메모리 = 총 크기 – (1024* 총 크기/16384).
DOP 매개변수인 "최대 병렬 처리 수준"을 제한하고 "1"로 설정합니다.
일정에 따라 통계를 업데이트합니다. SQL Server 2008부터 통계를 업데이트하면 쿼리가 다시 컴파일되어 절차적 캐시가 지워지므로 절차적 캐시를 지우기 위해 별도의 절차를 수행할 필요가 없습니다.
우리는 정기적으로 테이블을 다시 인덱싱하고 인덱스 조각 모음을 수행합니다.
올바른 예약 정책을 수립합니다. 시스템 충돌 전 마지막 시점으로 복구할 필요가 없고 마지막 5분 이상이 비즈니스에 중요하지 않은 경우 복구 모델을 "단순"으로 설정하십시오. 이렇게 하면 녹음 속도가 크게 빨라집니다. 가장 중요한 점은 지정된 시간 내에 차별화된 백업을 완료할 수 있다는 점입니다.
추가 데이터 파일을 생성하여 I/O 중에 TempDB 작업을 개선했습니다. 논리 프로세서가 8개 미만인 경우 각 논리 프로세서에 대해 데이터 파일을 생성하는 것이 좋습니다. 논리 프로세서가 8개보다 많은 경우 데이터 파일을 8개 생성하는 것이 좋으며, 4의 배수로 1씩 늘려서 TempDB의 로드를 추정해야 합니다.
현재로서는 동일한 MS SQL과 비교하여 1C:Enterprise 서버와 결합된 PostgreSQL의 성능이 많이 부족합니다. 이 기사는 PostgreSQL에서 적절한 성능을 달성하려는 시도의 연속입니다. 비록 현재로서는 MS SQL에 필적하는 성능을 달성할 수는 없지만 가까운 시일 내에 이 문제가 해결될 것이라고 생각합니다.
기본 PostgreSQL 매개변수.
공유_버퍼
PostgreSQL이 데이터 캐싱을 위해 할당하는 공유 메모리의 양은 각각 8KB의 shared_buffers 페이지 수에 따라 결정됩니다. 운영 체제 자체가 데이터를 캐시하므로 캐시에 사용 가능한 모든 RAM을 할당할 필요가 없다는 점을 고려해야 합니다. shared_buffers의 크기는 여러 요인에 따라 달라집니다. 우선 다음 값을 사용할 수 있습니다.
- 8~16MB– 512MB와 작은 데이터베이스를 갖춘 일반 데스크톱 컴퓨터,
- 80~160MB– 1GB의 RAM과 약 10GB의 데이터베이스를 제공하도록 설계된 소형 서버,
- 400MB– 메모리 용량이 8GB이고 데이터베이스가 100GB를 초과하며 수백 개의 활성 연결을 동시에 제공하는 여러 프로세서를 갖춘 서버입니다.
work_mem
각 요청마다 제한된 양의 메모리가 할당됩니다. 이 볼륨은 정렬, 병합 및 기타 유사한 작업에 사용됩니다. 이 볼륨을 초과하면 서버가 디스크의 임시 파일을 사용하기 시작하여 성능이 크게 저하될 수 있습니다. 사용 가능한 메모리 양(물리적 메모리에서 다른 프로그램 및 shared_buffers 페이지가 차지하는 양을 뺀 양)을 동시에 사용되는 최대 활성 연결 수로 나누어 work_mem에 필요한 값을 추정할 수 있습니다.
Maintenance_work_mem
이 메모리는 ANALYZE 통계 수집, VACUUM 가비지 수집, CREATE INDEX 및 외래 키 추가 작업을 수행하는 데 사용됩니다. 이러한 작업에 할당된 메모리 크기는 디스크에서 가장 큰 인덱스의 물리적 크기와 비슷해야 합니다.
유효_캐시_크기
PostgreSQL은 설계를 위해 운영 체제에서 제공하는 파일 캐싱을 사용합니다. 이 설정은 시스템 캐시에 들어갈 수 있는 개체의 최대 크기에 해당합니다. 이 값은 추정 목적으로만 사용됩니다. Effective_cache_size는 PostgreSQL에 모두 할당된 경우 사용 가능한 RAM 양의 ½ - 2/3로 설정할 수 있습니다.
주목!다음 옵션은 PostgreSQL 성능을 크게 향상시킬 수 있습니다. 그러나 배터리가 부족할 때 시스템을 종료하는 안정적인 UPS와 소프트웨어가 있는 경우에만 사용하는 것이 좋습니다.
fsync
이 매개변수는 트랜잭션이 완료될 때 캐시에서 디스크로 데이터를 플러시하는 역할을 합니다. 이 매개변수를 off로 설정하면 작업이 완료된 후 즉시 데이터가 디스크 드라이브에 기록되지 않습니다. 이를 통해 삽입 및 업데이트 작업 속도를 크게 향상시킬 수 있지만 오류가 발생하는 경우(예기치 않은 정전, OS 오류, 디스크 하위 시스템 오류) 데이터베이스가 손상될 위험이 있습니다.
fsync를 비활성화하고 하드웨어의 안정성에 의존하면 fsync 활성화로 인한 부정적인 영향을 줄일 수 있습니다. 또는 올바른 매개변수 wal_sync_method(데이터를 디스크에 강제로 기록하는 데 사용되는 방법)를 선택하면 됩니다.
가능한 값:
- open_datasync– O_DSYNC 매개변수와 함께 open() 메소드를 사용하여 데이터 쓰기,
- fdatasync– 각 커밋 후에 fdatasync() 메서드를 호출합니다.
- fsync_writethrough– 병렬 프로세스를 무시하고 각 커밋 후에 fsync()를 호출합니다.
- fsync– 각 커밋 후에 fsync()를 호출합니다.
- open_sync– O_SYNC 매개변수와 함께 open() 메소드를 사용하여 데이터 쓰기.
메모!특정 플랫폼에서는 모든 방법을 사용할 수 있는 것은 아닙니다. 선택하는 방법은 PostgreSQL이 실행되는 운영 체제에 따라 다릅니다.
PostgreSQL에는 유틸리티가 포함되어 있습니다. pg_test_fsync, 이를 통해 wal_sync_method 매개변수의 최적 값을 결정할 수 있습니다.
다양한 동기화 방법을 사용하여 일련의 디스크 테스트를 실행합니다. 이 테스트는 특정 운영 체제에 대한 최적의 동기화 방법을 결정하는 데 사용할 수 있는 디스크 시스템 성능 추정치를 제공합니다.
저는 다음 사양을 갖춘 업무용 컴퓨터에서 위의 테스트를 실행하기로 결정했습니다.
- CPU:인텔 코어 i3-3220 @ 3.30GHz x 2
- 램: 4GB
- HDD:씨게이트 ST3320418AS 320GB
Windows에서 테스트:
- OS:윈도우 7 얼티밋 x64
- FS: NTFS
- DBMS:포스트그레SQL 9.4.2-1.1C x64
| C:\PROGRA~1\POSTGR~1\9.4.2-1.1C\bin>pg_test_fsync테스트당 5초가 Linux의 기본값입니다) open_datasync 48817.440 ops/초 20 usecs/op fdatasync 해당 사항 없음 fsync 79.688 ops/초 12549 usecs/opfsync_writethrough 80.072 ops/초 12489 usecs/op open_sync 해당 사항 없음 (fdatasync를 제외한 wal_sync_method 기본 설정 순서) Linux의 기본값입니다) open_datasync 24713.634 ops/초 40 usecs/op fdatasync 해당 사항 없음 fsync 78.690 ops/초 12708 usecs/opfsync_writethrough 79.073 ops/초 12646 usecs/op open_sync 해당 없음 1 * 16kB open_sync 쓰기 해당 없음 2 * 8kB open_sync 쓰기 해당 없음 4 * 4kB open_sync 쓰기 해당 없음 8 * 2kB open_sync 쓰기 해당 없음 16 * 1kB open_sync 쓰기 해당 없음다른 설명자에 있습니다.) 쓰기, fsync, 닫기 76.493 ops/초 13073 usecs/op쓰기, 닫기, fsync 77.676 ops/sec 12874 usecs/op동기화되지 않은 8kB 쓰기: 쓰기 1800.319 ops/초 555 usecs/op |
테스트 결과에 따르면 Windows의 경우 open_datasync를 사용하는 것이 최적의 솔루션이라는 것을 알 수 있습니다.
Linux에서 테스트:
- OS:데비안 8.6 제시
- 핵심: x86_64 리눅스 3.16.0-4-amd64
- FS: ext4
- DBMS:포스트그레SQL 9.4.2-1.1C amd64
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | /usr/lib/postgresql/9.4/bin# ./pg_test_fsync테스트당 5초 이 플랫폼에서는 open_datasync 및 open_sync에 대해 O_DIRECT가 지원됩니다.하나의 8kB 쓰기를 사용하여 파일 동기화 방법을 비교합니다.(fdatasync를 제외한 wal_sync_method 기본 설정 순서) Linux의 기본값입니다) open_datasync 80.215 ops/초 12467 usecs/opfdatasync 80.349 ops/초 12446 usecs/opfsync 39.384 ops/초 25391 usecs/op fsync_writethrough 해당 사항 없음 open_sync 40.013 ops/초 24992 usecs/op두 개의 8kB 쓰기를 사용하여 파일 동기화 방법을 비교합니다.(fdatasync를 제외한 wal_sync_method 기본 설정 순서) Linux의 기본값입니다) open_datasync 40.033 ops/초 24980 usecs/opfdatasync 77.264 ops/초 12943 usecs/opfsync 36.325 ops/초 27529 usecs/op fsync_writethrough 해당 사항 없음 open_sync 19.659 ops/초 50866 usecs/opopen_sync를 다양한 쓰기 크기와 비교하세요.(이것은 16kB를 쓰는 비용을 비교하기 위해 고안되었습니다.다른 쓰기 open_sync 크기로.)1 * 16kB open_sync 쓰기 38.697 ops/sec 25842 usecs/op2 * 8kB open_sync 쓰기 17.356 ops/sec 57616 usecs/op4 * 4kB open_sync 쓰기 8.996 ops/sec 111156 usecs/op8 * 2kB open_sync 쓰기 4.552 ops/sec 219686 usecs/op16 * 1kB open_sync 쓰기 2.218 ops/sec 450930 usecs/op쓰기가 아닌 파일 설명자에 대한 fsync가 적용되는지 테스트합니다.(시간이 비슷한 경우 fsync()는 작성된 데이터를 동기화할 수 있습니다.다른 설명자에 있습니다.) 쓰기, fsync, 닫기 34.341 ops/sec 29120 usecs/op쓰기, 닫기, fsync 35.753 ops/sec 27970 usecs/op동기화되지 않은 8kB 쓰기: 쓰기 484193.516 ops/sec 2 usecs/op |
테스트 결과에 따르면 fdatasync 및 open_datasync 메서드가 최고의 속도를 제공하는 것으로 나타났습니다. 또한 동일한 하드웨어에서 Linux의 쓰기 속도는 Windows의 거의 절반에 불과하다는 것을 알 수 있습니다.
이 테스트에서는 하나의 디스크로 구성된 디스크 시스템을 사용했습니다. 많은 수의 디스크가 포함된 RAID 어레이를 사용하는 경우 그림이 다를 수 있습니다.
wal_buffers
트랜잭션 로그를 유지하기 위해 SHARED MEMORY에서 사용되는 메모리 양입니다. 사용 가능한 메모리가 1~4GB인 경우 256~1024KB를 설치하는 것이 좋습니다. 데이터베이스 테이블을 많이 수정한 시스템에서는 이 매개변수를 늘려야 합니다.
체크포인트_세그먼트
검사점 간 트랜잭션 로그의 세그먼트 수(각 16MB)를 정의합니다. 데이터 수정 트랜잭션이 많은 데이터베이스의 경우 이 매개변수를 늘리는 것이 좋습니다. 충분한 수의 세그먼트에 대한 기준은 체크포인트가 너무 자주 발생한다는 경고가 로그에 없다는 것입니다.
full_page_writes
이 옵션을 활성화하면 트랜잭션 로그에 기록되는 데이터 양이 늘어나지만 올바른 복구가 보장됩니다. 이 옵션을 비활성화하면 성능이 향상되지만 시스템 충돌이나 정전이 발생하는 경우 데이터베이스가 손상될 수 있습니다.
동기_커밋
각 트랜잭션 후 로그 파일에 대한 동기 쓰기를 활성화/비활성화합니다. 동기식 녹음을 활성화하면 데이터 손실 가능성을 방지할 수 있습니다. 그러나 서버 대역폭에는 제한이 있습니다. 트랜잭션 수 측면에서 더 나은 성능이 필요한 경우 동기 쓰기를 비활성화할 수 있습니다. 그리고 시스템이 충돌할 경우 소수의 변경 사항이 손실될 가능성이 낮다는 점은 중요하지 않습니다. 동기 녹음을 비활성화하려면 이 매개변수를 off로 설정합니다.
PostgreSQL 성능을 향상시키는 또 다른 방법은 트랜잭션 로그(pg_xlog)를 다른 디스크로 이동하는 것입니다. 트랜잭션 로그에 별도의 디스크 리소스를 할당하면 로드된 OLTP 시스템에 대해 10%-12%의 상당한 성능 향상을 얻을 수 있습니다.
Linux에서는 트랜잭션 로그 디렉터리의 새 위치에 대한 심볼릭 링크를 생성하여 이를 수행합니다.
Windows에서는 이러한 목적으로 유틸리티를 사용할 수 있습니다. 접합. 이렇게 하려면 다음이 필요합니다.
- PostgreSQL을 중지합니다.
- C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog 를 백업하세요.
- C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog 를 D:\pg_xlog 에 복사하고 C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog 를 삭제합니다.
- 프로그램 압축 풀기 접합 C:\Program Files\PostgreSQL\X.X.X\data 에 있습니다.
- 창 열기 명령, C:\Program Files\PostgreSQL\X.X.X\data로 이동하여junction -s pg_xlog D:\pg_xlog 를 실행하세요.
- postgres 사용자에 대해 D:\pg_xlog 폴더에 대한 권한을 설정합니다.
- PostgreSQL을 시작합니다.
X.X.X는 사용된 PostgreSQL 버전입니다.
PostgreSQL 작업 시 1C:Enterprise의 기능 및 제한 사항.
FULL EXTERNAL JOIN 디자인을 사용합니다.
PostgreSQL DBMS는 FULL OUTER JOIN을 부분적으로만 지원합니다(오류: "FULL JOIN은 mergejoinable 조인 조건에서만 지원됩니다"). PostgreSQL과 함께 1C:Enterprise 8을 실행할 때 FULL OUTER JOIN에 대한 완전한 지원을 구현하기 위해 유사한 쿼리가 동일한 결과를 갖는 다른 형식으로 변환되지만 FULL OUTER JOIN 구성 사용의 효율성이 감소됩니다.
PostgreSQL 작업 시 SliceLast 가상 테이블 사용을 최적화합니다.
문제: PostgreSQL로 작업할 때 SliceLast 가상 테이블에 대한 조인을 사용하면 성능이 크게 저하될 수 있습니다. 최적화 프로그램 오류로 인해 최적이 아닌 쿼리 실행 계획이 선택될 수 있습니다.
해결책:쿼리가 Last 쿼리 언어의 1C:Enterprise Slice에서 가상 테이블에 대한 연결을 사용하고 쿼리의 성능이 만족스럽지 못한 경우, 가상 테이블에 대한 호출을 별도의 쿼리로 만들어 결과를 저장하는 것이 좋습니다. 임시 테이블.
PostgreSQL 정지 문제를 해결합니다.
대규모 테이블 연결이 많은 복잡한 쿼리를 사용하는 일부 일상적인 작업(월 결산, 비용 계산 등)을 수행하는 경우 작업 실행 시간이 크게 늘어날 수 있습니다. 기본적으로 이러한 문제는 PostgreSQL 최적화 프로그램의 작업 및 쿼리에 참여하는 테이블에 대한 최신 통계 부족과 관련이 있습니다.
문제 해결을 위한 옵션:
- 테이블에 대한 통계 수집 시 조회되는 레코드 수를 늘립니다. 값이 클수록 ANALYZE 명령의 실행 시간이 늘어날 수 있지만 쿼리 계획 구성이 향상됩니다.
- 파일 postgresql.conf- default_statistics_target = 1000 -10000 .
- PostgreSQL 구성에서 쿼리 실행 계획을 선택할 때 NESTED LOOP를 사용하는 최적화 프로그램의 기능을 비활성화합니다.
- 파일 postgresql.conf-enable_nestloop = 꺼짐.
- 이 방법의 부정적인 효과는 일부 쿼리가 더 비용이 많이 드는 다른 조인 방법(HASH JOIN)을 사용하기 때문에 일부 쿼리의 속도를 저하시킬 수 있다는 것입니다.
- 쿼리에서 테이블 조인 순서를 변경하는 최적화 프로그램의 기능을 비활성화합니다.
- 파일 postgresql.conf- Join_collapse_limit=1 .
- 문제 쿼리의 테이블 조인 순서가 정확하다고 확신하는 경우 이 방법을 사용해야 합니다.
- 최적화 설정 변경:
- 파일 postgresql.conf:
- seq_page_cost = 0.1
- random_page_cost = 0.4
- cpu_operator_cost = 0.00025
- 파일 postgresql.conf:
- 테이블의 데이터 변경 사항에 대한 정보를 기반으로 AUTOVACUUM과 독립적으로 통계 수집을 구현하는 PostgreSQL 버전 9.1.2-1.1.C 이상을 사용합니다. 기본적으로 통계 수집은 임시 테이블에 대해서만 활성화되며 대부분의 경우 이것으로 충분합니다. 일상적인 작업 수행에 문제가 발생하는 경우 PostgreSQL 구성 매개변수(파일)의 값을 변경하여 전체 또는 개별 문제 테이블에 대한 통계 수집을 활성화할 수 있습니다. postgresql.conf) online_analyze.table_type = "임시" on online_analyze.table_type = "all" . 내 동지 Vasiliy P. Melnik. 인터페이스는 영어임에도 불구하고 간단하고 직관적입니다. 누구나 알아낼 수 있다고 생각합니다.