আমার একটি টাইলমিল / পোস্টজিআইএস স্ট্যাক একটি ওপেনস্ট্যাক ক্লাউডে একটি 8 কোর উবুন্টু 12.04 ভিএম চলছে। এটি একটি খুব অনুরূপ সিস্টেমের একটি পুনর্নির্মাণ যা গত সপ্তাহে খুব একই ধরণের হার্ডওয়্যার (একই মেঘ, তবে বিভিন্ন শারীরিক হার্ডওয়্যার, আমি বিশ্বাস করি) উপর দুর্দান্তভাবে চলছিল। আমি স্ট্যাকটি ঠিক ঠিক একইভাবে পুনর্নির্মাণের চেষ্টা করেছি (আমি তৈরি কিছু স্ক্রিপ্ট ব্যবহার করে)।
সবকিছু চলতে থাকে, তবে ডাটাবেসগুলি ধীরে ধীরে ধীরে ধীরে প্রশ্নগুলি চালাচ্ছে, যা খুব ধীরে ধীরে টাইল প্রজন্মের সাথে নিজেকে প্রকাশ করে। একটি উদাহরণ ক্যোয়ারী (অস্ট্রেলিয়ার প্রতিটি শহরে ব্যাসার্ধের মধ্যে থাকা পাবগুলির সংখ্যা গণনা করুন), যা আগে 10-20 সেকেন্ডের মতো কিছু নিয়েছিল এখন 10 মিনিটের বেশি সময় নিবে:
explain (analyze, buffers) update places set pubs =
(select count(*) from planet_osm_point p where p.amenity = 'pub' and st_dwithin(p.way,places.way,scope)) +
(select count(*) from planet_osm_polygon p where p.amenity = 'pub' and st_dwithin(p.way,places.way,scope)) ;
Update on places (cost=0.00..948254806.93 rows=9037 width=160) (actual time=623321.558..623321.558 rows=0 loops=1)
Buffers: shared hit=132126300
-> Seq Scan on places (cost=0.00..948254806.93 rows=9037 width=160) (actual time=68.130..622931.130 rows=9037 loops=1)
Buffers: shared hit=132107781
SubPlan 1
-> Aggregate (cost=12.95..12.96 rows=1 width=0) (actual time=0.187..0.188 rows=1 loops=9037)
Buffers: shared hit=158171
-> Index Scan using planet_osm_point_index on planet_osm_point p (cost=0.00..12.94 rows=1 width=0) (actual time=0.163..0.179 rows=0 loops=9037)
Index Cond: (way && st_expand(places.way, (places.scope)::double precision))
Filter: ((amenity = 'pub'::text) AND (places.way && st_expand(way, (places.scope)::double precision)) AND _st_dwithin(way, places.way, (places.scope)::double precision))
Buffers: shared hit=158171
SubPlan 2
-> Aggregate (cost=104917.24..104917.25 rows=1 width=0) (actual time=68.727..68.728 rows=1 loops=9037)
Buffers: shared hit=131949237
-> Seq Scan on planet_osm_polygon p (cost=0.00..104917.24 rows=1 width=0) (actual time=68.138..68.716 rows=0 loops=9037)
Filter: ((amenity = 'pub'::text) AND (way && st_expand(places.way, (places.scope)::double precision)) AND (places.way && st_expand(way, (places.scope)::double precision)) AND _st_dwithin(way, places.way, (places.scope)::double precision))
Buffers: shared hit=131949237
Total runtime: 623321.801 ms
(আমি এই কোয়েরিটিকে একটি লক্ষণ হিসাবে অন্তর্ভুক্ত করছি, সমস্যার সমাধান করার জন্য সরাসরি নয় particular এই বিশেষ ক্যোয়ারীটি সপ্তাহে বা আরও একবার চালানো হয়))
সার্ভারে র্যামি 32 গিগাবাইট রয়েছে, এবং আমি পোস্টগ্র্রেসটি নীচের অনুসারে কনফিগার করেছি (ওয়েবে প্রাপ্ত নিম্নলিখিত পরামর্শগুলি):
shared_buffers = 8GB
autovacuum = on
effective_cache_size = 8GB
work_mem = 128MB
maintenance_work_mem = 64MB
wal_buffers = 1MB
checkpoint_segments = 10
iostat কিছুই পড়ছে না, কিছুটা ডেটা লিখিত হয়েছে (কোথায় বা কেন হয় না) এবং 95% নিষ্ক্রিয় সিপিইউ দেখায়:
avg-cpu: %user %nice %system %iowait %steal %idle
5.40 0.00 0.00 0.11 0.00 94.49
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 0.20 0.00 0.80 0 8
vdb 2.30 0.00 17.58 0 176
থেকে নমুনা আউটপুট vmstat:
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
...
1 0 0 18329748 126108 12600436 0 0 0 18 148 140 5 0 95 0
2 0 0 18329400 126124 12600436 0 0 0 9 173 228 5 0 95 0
স্ট্রচে আটকে আমি পোস্টগ্র্রেস ডেটা ডিরেক্টরিটি ভিডিএ থেকে ভিডিবিতে স্থানান্তরিত করেছি তবে অবশ্যই এতে কোনও পার্থক্য হয়নি।
তাই আমি ক্ষতিতে আছি। পোস্টগ্র্রেস কেন কেবলমাত্র 5% উপলব্ধ সিপিইউ ব্যবহার করে যখন এটি কোনও আই / ও এর জন্য অপেক্ষা না করে? আমি আরও তদন্ত, অন্য সরঞ্জাম, চেষ্টা করার এলোমেলো জিনিসগুলির জন্য যে কোনও পরামর্শকে স্বাগত জানাব।
হালনাগাদ
আমি সার্ভারটি স্ন্যাপশট করে এটিকে একই মেঘের ভিন্ন অংশে (একটি ভিন্ন প্রাপ্যতা অঞ্চল) চালু করেছিলাম। ফলাফলগুলি কিছুটা অদ্ভুত ছিল। vmstatএই সার্ভারে 12% সিপিইউ ব্যবহারের রিপোর্ট করেছে (যা আমি এখন 8 টি ভিও ভিএম-তে একক পোস্টগ্রিজ ক্যোয়ারির জন্য প্রত্যাশিত মান হিসাবে বুঝতে পারি) - যদিও প্রকৃত ক্যোয়ারী এক্সিকিউশন সময়টি কার্যত অভিন্ন (630 সেকেন্ড বনাম 623)।
আমি এখন বুঝতে পারি যে এই বিশেষ ক্যোয়ারী সম্ভবত এই কারণে ভাল নমুনা নয়: এটি কেবলমাত্র একটি কোর ব্যবহার করতে পারে, এবং এটি একটি update(যেখানে টাইল রেন্ডারিং কেবলমাত্র select)।
আমি এটাও লক্ষ্য করিনি explainযে দৃশ্যত planet_osm_polygonকোনও সূচক ব্যবহার করছে না। এটি কারণ হতে পারে, তাই আমি এটি পরবর্তী তাড়া করব।
Update2
সমস্যাটি স্পষ্টতই মনে হচ্ছে যে গ্রহ_সম_পলিগন সূচক (এস) ব্যবহার করা হচ্ছে না / হচ্ছে। দুটি আছে (একটি osm2pgsql দ্বারা তৈরি, একটি এলোমেলো গাইড অনুসরণ করে আমার দ্বারা নির্মিত):
CREATE INDEX idx_planet_osm_polygon_tags
ON planet_osm_polygon
USING gist
(tags);
CREATE INDEX planet_osm_polygon_pkey
ON planet_osm_polygon
USING btree
(osm_id);
প্ল্যানেট_সোম_পলিগন এবং গ্রহ_সোম_পয়েন্টের পরিসংখ্যানগুলি বেশ প্রকাশ করে, আমার মনে হয়:
planet_osm_polygon:
Sequential Scans 194204
Sequential Tuples Read 60981018608
Index Scans 1574
Index Tuples Fetched 0
planet_osm_point:
Sequential Scans 1142
Sequential Tuples Read 12960604
Index Scans 183454
Index Tuples Fetched 43427685
যদি আমি এটি সঠিকভাবে পড়ে থাকি তবে পোস্টগ্রিস 1574 বার গ্রহ_সম_পলিগন অনুসন্ধান করেছে, কিন্তু বাস্তবে কখনও কিছুই খুঁজে পেল না, তাই একটি হাস্যকরভাবে বিপুল সংখ্যক নৃশংস অনুসন্ধান করেছে।
নতুন প্রশ্ন: কেন?
রহস্য সমাধান
ফ্রেডেরিক র্যামের উত্তরের জন্য ধন্যবাদ , উত্তরটি মোটামুটি সহজ বলে প্রমাণিত হয়েছে: কোনও কারণে কোনও স্থানিক সূচক ছিল না। এগুলি পুনরায় জন্মানোতে তুচ্ছ ছিল:
create index planet_osm_polygon_polygon on planet_osm_polygon using gist(way);
create index planet_osm_polygon_point on planet_osm_point using gist(way);
এই ক্যোয়ারীটি চালাতে এখন 4.6 সেকেন্ড সময় লাগে। স্থানিক সূচকের বিষয়টি! :)