পোস্টগ্র্রেসকিল ডাটাবেস ব্যবহার করে এমন ওয়েবসাইট অ্যাক্সেস করার চেষ্টা করা বা পিএসএইচএল ইউটিলিটি বা প্যাগডমিন 3 ব্যবহার করার সময় আমি হঠাৎ এই ত্রুটিটি পেয়ে যাচ্ছি।
আমার ডাটাবেস 150 সর্বোচ্চ সংযোগ পরিচালনা করতে সেট করা হয়েছে:
# SHOW max_connections;
max_connections
-----------------
150
(1 row)
আমার ওয়েবসাইটটিতে থাকা উবুন্টু সার্ভারটি পুনরায় চালু করার পরে (যা সংযোগগুলি ব্যবহার করার ক্ষেত্রে কেবলমাত্র একমাত্র জিনিস), আমি দেখছি সংযোগের বর্তমান পরিমাণ ১৪০:
# select count(*) from pg_stat_activity;
count
-------
140
(1 row)
আমার সার্ভারটি রিবুট করার পরে হঠাৎ এত সংযোগগুলি কীভাবে বুঝতে পারছি না। সুতরাং আমি পোস্টগ্র্যাস্কিল কার্যকলাপটি পরীক্ষা করি:
# SELECT * FROM pg_stat_activity;
এবং আমি দেখতে দেখতে একই সঠিক ক্যোয়ারী সহ 100 টিরও বেশি কলাম দেখছি:
SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1
আরও গুরুত্বপূর্ণ এটি তাদের সবার একই ক্লায়েন্ট ঠিকানা (আমার ওয়েব সার্ভার) রয়েছে।
এই ওয়েব সার্ভারটি 50 এর সংযোগ পুলের সাহায্যে রেলকে রেল ব্যবহার করছে 50 সেখানে 50 এর সংযোগ পুল থাকা সত্ত্বেও, যাত্রী প্রক্রিয়া / প্রিফের্ক অ্যাপাচি কনফিগারেশনটি একক থ্রেডযুক্ত এবং তাই প্রতিটি প্রক্রিয়া 50 টি থ্রেড এবং 50 টি ডাটাবেস সংযোগ স্প্যান করতে পারে না। আর কি হ'ল এটি একটি সিস্টেম রিবুট হওয়ার পরে ঘটেছিল যা আমার ব্যবহারকারীদের আমার সার্ভার থেকে সরিয়ে দেয় ocked সম্ভাবনা হ'ল ডেটাবেস সার্ভারে পোস্টগ্রেকল ওয়েব সার্ভার পুনরায় বুট করার বিষয়ে সচেতন নয় এবং এখনও এই অনুসন্ধানগুলি কার্যকর করার চেষ্টা করছে।
ক্রেগের মন্তব্যের জবাব দেওয়ার জন্য, অপেক্ষার কলামের অধীনে এটি 'চ' অক্ষরটি দেখায়। দেখা যাচ্ছে যে ক্যোয়ারীটি এখনও কার্যকর হচ্ছে এবং লকটি এখনও প্রকাশ করা হয়নি। যেমনটি আমি আগেই বলেছি, কী আশ্চর্যজনক তা হ'ল হঠাৎ মিলিসেকেন্ডের মধ্যে 100 টিরও বেশি প্রশ্নের একে অপরের সাথে অভিন্ন হঠাৎ এই মৃত্যুদন্ডের স্থলে হাজির। এটাই আমার কাছে রহস্য:
mydb=# SELECT * FROM pg_stat_activity;
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
--------+----------+---------+----------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+----------------+-------------
464875 | mydb | 4992 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:44.089764-04 | 192.111.11.111 | 37166
464875 | mydb | 4993 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:44.277856-04 | 192.111.11.111 | 37167
464875 | mydb | 4994 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:44.485269-04 | 192.111.11.111 | 37168
464875 | mydb | 4996 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:44.688203-04 | 192.111.11.111 | 37169
464875 | mydb | 4998 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:44.703883-04 | 192.111.11.111 | 37170
-- many more
464875 | mydb | 5052 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:51.85682-04 | 192.111.11.111 | 37360
464875 | mydb | 5053 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:52.083316-04 | 192.111.11.111 | 37367
464875 | mydb | 8958 | 16387 | myuser | <IDLE> | f | | 2014-06-29 00:05:06.735249-04 | 2014-06-27 16:34:39.307312-04 | 192.111.11.111 | 52759
464875 | mydb | 5054 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:52.285867-04 | 192.111.11.111 | 37371
464875 | mydb | 5055 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:52.303562-04 | 192.111.11.111 | 37372
464875 | mydb | 5056 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:52.31447-04 | 192.111.11.111 | 37373
464875 | mydb | 5057 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:52.323721-04 | 192.111.11.111 | 37374
464875 | mydb | 5058 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:52.334238-04 | 192.111.11.111 | 37375
464875 | mydb | 5059 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:52.347227-04 | 192.111.11.111 | 37376
464875 | mydb | 5060 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:46:52.360008-04 | 192.111.11.111 | 37377
464875 | mydb | 5061 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:52.369496-04 | 192.111.11.111 | 37378
top
এই প্রক্রিয়াগুলি ব্যস্ত কিনা তা আপনার সার্ভারে পরীক্ষা করার প্রয়োজন হতে পারে । যদি সেগুলি হয়, তবে আমি মনে করি যে কোয়েরিগুলি শেষ হওয়ার পরে সংযোগগুলি অদৃশ্য হয়ে যাবে (বা বিকল্পভাবে, আপনি এখনই সেগুলি হত্যা করতে পারেন)। যদি তারা অলস থাকে, এবং সংযোগগুলি অবশ্যই মারা যায় তবে আমি কী করছি তা নিশ্চিত নই বা পরবর্তী সময় কীভাবে এটি প্রতিরোধ করা যায় ...
waiting
পতাকাটি চেক করুন pg_stat_activity
, দেখুন তারা লকটিতে আটকে আছে কিনা।
SELECT * FROM pg_stat_activity;
তা বিশ্বাসযোগ্য নয় - পর্যাপ্ত কলাম নেই are রাষ্ট্র কলাম কী বলে? এটি এই প্রশ্নের সবচেয়ে গুরুত্বপূর্ণ ক্ষেত্র
pg_stat_activity.backend_start
। এই সংযোগগুলি কি ওয়েব সার্ভার পুনরায় চালু হওয়ার আগে বা পরে তৈরি হয়েছিল? যদি তারা সমস্ত নতুন সংযোগ হয় তবে আমি ভাবতে পারি যে ওয়েব সার্ভারের শেষে সমস্যাটি রয়েছে।