Tại sao bảng phiên Django phát triển trên PostgreSQL


7

Tôi sử dụng PostgreSQL 9.1.6 thông qua PGBouncer 1.4.2 trong dự án Django 1.4.8 của tôi. django_sessionbảng phát triển tất cả các thời gian. VACUUM không giúp đỡ. VACUUM FULL chạy hàng giờ. Chỉ TRUNCATEgiúp thường xuyên.

Bảng chứa các hàng khoảng 10KB. Nó được cập nhật 40 lần / giây.

# SELECT table_name, pg_size_pretty(table_size) AS table_size, pg_size_pretty(indexes_size) AS indexes_size, pg_size_pretty(total_size) AS total_size
FROM (
    SELECT table_name, pg_table_size(table_name) AS table_size, pg_indexes_size(table_name) AS indexes_size, pg_total_relation_size(table_name) AS total_size
    FROM (
        SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name
        FROM information_schema.tables
    ) AS all_tables ORDER BY total_size DESC LIMIT 1
) AS pretty_sizes;
        table_name         | table_size | indexes_size | total_size 
---------------------------+------------+--------------+------------
 "public"."django_session" | 35 GB      | 209 MB       | 35 GB
(1 row)

# SELECT COUNT(*) FROM django_session;
 count 
-------
 40196

Một lệnh dọn dẹp được thực hiện bởi cron mỗi đêm.

./manage.py cleanup && echo "vacuum (analyze, verbose);" | ./manage.py dbshell

Có một cái gì đó thú vị về django_session trong đầu ra.

INFO:  vacuuming "public.django_session"
INFO:  scanned index "django_session_pkey" to remove 5338 row versions
DETAIL:  CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  scanned index "django_session_expire_date" to remove 5338 row versions
DETAIL:  CPU 0.10s/0.06u sec elapsed 3.47 sec.
INFO:  "django_session": removed 5338 row versions in 187 pages
DETAIL:  CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  index "django_session_pkey" now contains 71568 row versions in 1647 pages
DETAIL:  0 index row versions were removed.
4 index pages have been deleted, 4 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "django_session_expire_date" now contains 71568 row versions in 25049 pages
DETAIL:  2785 index row versions were removed.
1804 index pages have been deleted, 1798 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "django_session": found 0 removable, 71568 nonremovable row versions in 3386 out of 3386 pages
DETAIL:  46699 dead row versions cannot be removed yet.
There were 811150 unused item pointers.
0 pages are entirely empty.
CPU 0.11s/0.10u sec elapsed 16.00 sec.
...
INFO:  analyzing "public.django_session"
INFO:  "django_session": scanned 3460 of 3460 pages, containing 25514 live rows and 288939 dead rows; 25514 rows in sample, 25514 estimated total rows

Tôi đang tự hỏi về 46699 phiên bản hàng chết , 811150 con trỏ mục không sử dụng288939 hàng chết . Nhiều nguồn tin cho biết vấn đề là quá trình "nhàn rỗi trong giao dịch". Tôi nghĩ đây là trường hợp của tôi vì có rất nhiều quá trình như vậy:

# SELECT COUNT(*) FROM pg_stat_activity WHERE current_query = '<IDLE> in transaction';
 count 
-------
    30

Nhưng không có truy vấn thực sự cũ.

# SELECT age(now(), query_start) AS "age" FROM pg_stat_activity ORDER BY query_start LIMIT 1;
       age       
-----------------
 00:00:00.241521

Số lượng lớn các quy trình nhàn rỗi có thể là do TransactionMiddleware.

Vì vậy, bây giờ tôi không có bất kỳ ý tưởng. Tôi đã thực hiện lệnh dọn dẹp bằng tay và nó hoạt động tốt, vì vậy tôi quyết định vấn đề đã được giải quyết bằng cách nào đó và cắt bớt bảng. Nhưng nó lại phát triển.

Biểu đồ tăng trưởng bảng

# select * from pgstattuple('django_session');
-[ RECORD 1 ]------+---------
table_len          | 23003136
tuple_count        | 32139
tuple_len          | 11201544
tuple_percent      | 48.7
dead_tuple_count   | 1729
dead_tuple_len     | 171632
dead_tuple_percent | 0.75
free_space         | 8930044
free_percent       | 38.82

Điều gì có thể gây ra vấn đề kỳ lạ như vậy?

CẬP NHẬT:

Tôi đã xóa Giao dịch viên và chuyển sang chế độ giao dịch trong PGBouncer. Hiện tại gần như không có quy trình 'nhàn rỗi trong giao dịch'. Nhưng điều này không giúp được gì.

$ echo $(for i in `seq 100`; do echo "SELECT COUNT(*) FROM pg_stat_activity WHERE current_query = '<IDLE> in transaction';" | sudo -u postgres psql mydb | grep  ' 0'; sleep 0.1; done | wc -l)"% of time there is NO idle in transaction processes"

75% of time there is NO idle in transaction processes

1
"Không hoạt động trong giao dịch" dẫn đến một VACUUM không thể dọn sạch các hồ sơ mà tôi có thể sử dụng trong các giao dịch này. Điều gì gây ra các giao dịch nhàn rỗi?
Frank Heikens

Cảm ơn bình luận của bạn! Tôi nghĩ rằng chúng được gây ra bởi chế độ phiên PGBouncer và TransactionMiddleware. Tất cả các bộ xử lý yêu cầu http được gói vào một giao dịch db và sử dụng kết nối db liên tục. Nhưng bây giờ tôi đã vô hiệu hóa TransactionMiddleware và chuyển pgbouncer sang chế độ giao dịch, do đó không còn giao dịch chạy dài và không có kết nối liên tục nữa. Số lượng '<IDLE> trong quy trình giao dịch' là 0 ngay bây giờ (và đôi khi là 1). Vì vậy, có vẻ như "nhàn rỗi trong giao dịch" không phải là vấn đề đối với tôi, phải không?
raacer

Câu trả lời:


0

Đầu tiên! Nâng cấp lên 9.1.10 (chỉ cần cài đặt nhị phân mới và khởi động lại DB).

Tôi sẽ làm như sau:

  1. đảm bảo không có phiên chạy dài, điều này có nghĩa là sẽ không có giao dịch dài;
  2. bạn đã không đề cập đến autovacuumcài đặt của mình , do đó tôi chắc chắn autovacuumsẽ chạy;
  3. Tôi đã điều chỉnh các ngưỡng tự động điều chỉnh cho bảng được đề cập , django_session;
  4. CLUSTER bảng, sử dụng chỉ mục khóa chính.

Nó cũng rất thú vị để kiểm tra nội dung của các pg_stat_%khung nhìn cho bảng đặc biệt này. Tôi có cảm giác, đánh giá bằng số lượng lớn các mục chết trong chỉ mục PK, rằng Django đang xây dựng các UPDATEtruy vấn động , cập nhật tất cả các cột của bộ dữ liệu. Nếu điều này là đúng, thì nó giải thích tình huống bạn nhìn thấy.


0

OK, đây là câu trả lời của tôi sau nhiều nghiên cứu.

Đừng chạy máy chủ PostgreQuery đã tải nặng trên một máy ảo như KVM. Nó thiếu tốc độ i / o ngay cả với trình điều khiển thích hợp để truy cập trực tiếp vào hdd.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.