পিএসকিএল: ফ্যাটাল: দুঃখিত, ইতিমধ্যে অনেকগুলি ক্লায়েন্ট


16

পোস্টগ্র্রেসকিল ডাটাবেস ব্যবহার করে এমন ওয়েবসাইট অ্যাক্সেস করার চেষ্টা করা বা পিএসএইচএল ইউটিলিটি বা প্যাগডমিন 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

একবার দেখুন pg_stat_activity.backend_start। এই সংযোগগুলি কি ওয়েব সার্ভার পুনরায় চালু হওয়ার আগে বা পরে তৈরি হয়েছিল? যদি তারা সমস্ত নতুন সংযোগ হয় তবে আমি ভাবতে পারি যে ওয়েব সার্ভারের শেষে সমস্যাটি রয়েছে।
নিক বার্নস

@ নিকবার্নস এই সংযোগগুলির সমস্ত "কারেন্ট_কোয়ারি" কলামের আওতায় একই প্রশ্ন রয়েছে এবং ব্যাকএন্ড_স্টার্ট সময় কার্যতঃ তাদের সকলের জন্য একই রকম (মিলি সেকেন্ড আলাদা)। এটিই এত অদ্ভুত এবং আমি বিশ্বাস করি যদি স্মৃতি আমাকে সঠিকভাবে পরিবেশন করে তবে সেগুলি পুনরায় বুটের আগেই ছিল। তবে আমি ধরে নিয়েছিলাম যে রিবুটটি সংযোগটি ভেঙে দেবে।
জনমারলিনো

1
ঠিক আছে ... topএই প্রক্রিয়াগুলি ব্যস্ত কিনা তা আপনার সার্ভারে পরীক্ষা করার প্রয়োজন হতে পারে । যদি সেগুলি হয়, তবে আমি মনে করি যে কোয়েরিগুলি শেষ হওয়ার পরে সংযোগগুলি অদৃশ্য হয়ে যাবে (বা বিকল্পভাবে, আপনি এখনই সেগুলি হত্যা করতে পারেন)। যদি তারা অলস থাকে, এবং সংযোগগুলি অবশ্যই মারা যায় তবে আমি কী করছি তা নিশ্চিত নই বা পরবর্তী সময় কীভাবে এটি প্রতিরোধ করা যায় ...
নিক বার্নস

1
waitingপতাকাটি চেক করুন pg_stat_activity, দেখুন তারা লকটিতে আটকে আছে কিনা।
ক্রেগ রিঞ্জার

1
আপনি যে আউটপুটটি আটকিয়েছেন SELECT * FROM pg_stat_activity;তা বিশ্বাসযোগ্য নয় - পর্যাপ্ত কলাম নেই are রাষ্ট্র কলাম কী বলে? এটি এই প্রশ্নের সবচেয়ে গুরুত্বপূর্ণ ক্ষেত্র
ইলিউম্যান

উত্তর:


5

এটি ক্লায়েন্ট প্রোগ্রামিং নির্দিষ্ট সমস্যা বলে মনে হচ্ছে। আপনি উদাহরণস্বরূপ "সর্বোচ্চ_সংযোগ" পরামিতি উত্থাপনের মাধ্যমে এটি ঠিক করতে সক্ষম হবেন না।

আমি একটি সম্পর্কিত সম্পর্কিত সমস্যা পেয়েছি: রুবি ডাটাবেস সংযোগ পুলিং

যদিও আপনি আরও কিছু সার্ভার সাইড ডিবাগিং করতে পারেন:

"লগ_ সংযোগগুলি" এবং "লগ_দিকল্পগুলি" সক্ষম করুন। "% M% a% p" সহ "লগ_লাইন_প্রিফিক্স" ব্যবহার করুন।

পোস্টগ্রিগ এসকিউএল সার্ভারগুলি ডিবাগ করার জন্য খুব দরকারী অ্যাপ্লিকেশনগুলি পাও বা আরও অনেকগুলি শীর্ষগুলি রয়েছে: পিজি_একটিভিটি

রিয়েলটাইম সার্ভার ডিবাগিংয়ের জন্য আমি পিজি_একটিভিটি পছন্দ করি - বিশেষত ব্লকার প্রদর্শন এবং সেশনগুলি মেরে ফেলার জন্য এটি বৈশিষ্ট্য সহ।


-4

সমস্যাটি সমাধানের এটি সর্বোত্তম উপায় ... এটি কাজ করে

এসএসএইচ পুট্টি ব্যবহার করে সার্ভারে লগ ইন করুন,

sudo /etc/init.d/postgresql থামুন

এটি তখন ডেটাবেসে ডেড লগ প্রক্রিয়াগুলিকে মেরে ফেলে,

sudo /etc/init.d/postgresql শুরু করুন


6
এবং তারপরে আপনি কি আবার কোনও প্রোডাকশন সার্ভার বন্ধ করবেন? আপনার সমাধানটি স্পষ্টভাবে আটকে থাকা প্রক্রিয়াগুলি সরিয়ে দেয়, তবে তারা কেন সেখানে রয়েছে তা ব্যাখ্যা করে না বা টেকসই হয় না।
dezso
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.