HestiaCP PHP-FPM वर जास्त काम आहे का? डायनॅमिक वेब पेज ५०० मध्ये त्रुटी? हे ऑप्टिमायझेशन ताबडतोब प्रभावी होईल!

लेख निर्देशिका

तुम्हाला कधी अशा परिस्थितीचा अनुभव आला आहे का? तुमची वेबसाइट अचानक मंदावते, किंवा 500 एरर दाखवते. PHP-FPM रीस्टार्ट केल्यावर ती पूर्ववत होते , पण काही वेळाने तीच समस्या पुन्हा उद्भवते? हे खूपच निराशाजनक असते!

असे का घडते? खरे तर, हे सहसा अयोग्य PHP-FPM प्रोसेस पूल कॉन्फिगरेशन किंवा अपुऱ्या सर्व्हर संसाधनांमुळे होते. आज, आपण आपल्या वेबसाइटची अभेद्य स्थिरता सुनिश्चित करण्यासाठी HestiaCP अंतर्गत PHP-FPM ला पूर्णपणे ऑप्टिमाइझ करणार आहोत !

PHP-FPM ओव्हरलोड होण्याचे मुख्य कारण

PHP-FPM हे PHP साठीचे प्रोसेस मॅनेजर आहे , जे डायनॅमिक रिक्वेस्ट्स हाताळण्यासाठी जबाबदार असते. अयोग्य कॉन्फिगरेशनमुळे खालील गोष्टी घडू शकतात:

  • सर्व्हर संसाधने संपली आहेत., ज्यामुळे PHP-FPM नवीन विनंत्यांना वेळेवर प्रतिसाद देऊ शकत नाही;
  • खूप कमी प्रक्रिया, जेव्हा रहदारी अचानक वाढते तेव्हा ती वेळेत प्रक्रिया करता येत नाही;
  • प्रक्रियेचा वापर खूप जास्त आहे., ज्यामुळे CPU लोडचा स्फोट होतो.

HestiaCP PHP-FPM वर जास्त काम आहे का? डायनॅमिक वेब पेज ५०० मध्ये त्रुटी? हे ऑप्टिमायझेशन ताबडतोब प्रभावी होईल!

PHP-FPM ओव्हरलोड आहे की नाही हे कसे ओळखावे?

वापरू शकता tophtop CPU आणि मेमरी वापर पाहण्यासाठी कमांड:

top -c

जर तुम्हाला खालील सारखी प्रक्रिया माहिती दिसली, तर याचा अर्थ असा की PHP-FPM जास्त लोडखाली चालू आहे:

1669293 abc     20   0  790284 227880 185568 R  73.1   0.9   1:30.09 php-fpm: pool chenweiliang.com                                                    
1669522 abc     20   0  801924 224224 170236 R  69.9   0.9   0:59.01 php-fpm: pool chenweiliang.com

या प्रक्रिया ७०% पेक्षा जास्त CPU वापरत असल्याचे तुमच्या लक्षात येते का? जर असे वारंवार होत असेल, तर तुमच्या PHP-FPM मध्ये नक्कीच काहीतरी गडबड आहे!

तर, सर्व्हर ओव्हरलोड होणार नाही म्हणून आपण PHP-FPM कॉन्फिगरेशन कसे ऑप्टिमाइझ करू शकतो?

PHP-FPM प्रक्रिया पूल ऑप्टिमायझेशन (कोर पॅरामीटर समायोजन)

प्रथम, उघडा php-fpm कॉन्फिगरेशन फाइल्स:

sudo nano /etc/php/*/fpm/pool.d/www.conf
  • *तुमच्या PHP आवृत्तीमध्ये बदला, जसे की PHP8.5, आणि ते असे बदला:/etc/php/8.3/fpm/pool.d/www.conf

HestiaCP ने सेट केलेल्या PHP आवृत्तीची चौकशी करा.

v-list-web-domain user domain.com

उदा:

v-list-web-domain abc chenweiliang.com

आउटपुटमध्ये, तुम्हाला असे काहीतरी दिसेल:

PHP SUPPORT      yes
PHP MODE        php-fpm
PHP VERSION     8.5 

यावरून असे दिसून येते की वेबसाइट PHP 8.5 वापरते.

चला तुमच्या PHP-FPM कॉन्फिगरेशनवर एक नजर टाकूया:

[chenweiliang.com]
listen = /run/php/php8.5-fpm-chenweiliang.com.sock
listen.owner = abc
listen.group = www-data
listen.mode = 0660

user = abc
group = abc

pm = ondemand
pm.max_children = 8
pm.max_requests = 4000
pm.process_idle_timeout = 10s

तुम्ही पाहू शकता की तुमचे pm वापरलेला आहे ondemand,जरी ते निष्क्रिय वेळेत संसाधनांचा वापर कमी करू शकते, परंतु जेव्हा रहदारी अचानक वाढते तेव्हा प्रक्रिया वेळेत प्रतिसाद देऊ शकत नाही., परिणामी ५०० त्रुटी आली.

www.conf: सिस्टमचा अंगभूत "युनिव्हर्सल रिसोर्स पूल"

PHP-FPM इन्स्टॉल केल्यानंतर, सिस्टम तुम्हाला आपोआप एक... प्रदान करेल. www.conf दस्तऐवज.
त्याचेपोझिशनिंगहे खूप सोपे आहे—हा एक डीफॉल्ट प्रोसेस पूल आहे जो थेट वापरण्यासाठी तयार असतो आणि सहसा...ला जोडलेला असतो. www-data वापरकर्त्याने डाउनलोड केले.

या प्रकारचा पूल विशेषतः सिंगल-साइट वातावरणासाठी योग्य आहे: याचे कॉन्फिगरेशन हलकेफुलके असते आणि सर्व पॅरामीटर्स सामान्य टेम्पलेट्स असतात, जसे की:

user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm.max_children = 5

जर तुम्ही फक्त एकच साइट होस्ट करत असाल, तर तुम्ही कोणत्याही अतिरिक्त त्रासाशिवाय तिचा थेट आणि खात्रीशीरपणे वापर करू शकता.

etUFO हे.org.conf: सानुकूल पूल

एकदा तुम्ही एकापेक्षा जास्त साईट्स चालवू लागलात की, तुम्ही सर्वांना एकाच पूलमध्ये कोंडून ठेवू शकत नाही.
या टप्प्यावर, HestiaCP प्रत्येक साइटसाठी आपोआप एक स्वतंत्र पूल तयार करेल, उदाहरणार्थ... etUFO हे.org.confडोमेन नावांमध्ये विशेषज्ञ etufo.org 服务。

खेळण्याची सामान्य पद्धत अशी आहे:

  • वापरकर्ते आणि गट बदला:user = etufo,group = etufo
  • स्वतंत्र देखरेख:listen = /run/php/etufo.sock
  • प्रक्रियांची संख्या समायोजित केल्याने उच्च समवर्तीतेच्या परिस्थितीतही अभेद्य स्थिरता सुनिश्चित होते.
  • स्वतंत्र लॉग फाइल्समुळे समस्यानिवारण अधिक स्पष्ट होते.

याचे फायदे स्पष्ट आहेत: सुरक्षित विलगीकरण . जरी एक साइट हॅक झाली, तरी इतरांवर कोणताही परिणाम होत नाही.

dummy.conf: डमी फाईल

डमी.कॉन्फ ही सहसा प्रणालीद्वारे प्रदान केलेली उदाहरणे किंवा नमुने असतात.
जोपर्यंत तुम्ही स्वतःहून त्यात बदल करून ते सक्षम करत नाही, तोपर्यंत ते प्रत्यक्षात चालणार नाही.
त्याचे महत्त्व एखाद्या 'ऑपरेशन मॅन्युअल'सारखे आहे, जे तुम्हाला नवीन पूल कॉन्फिगरेशन कसे लिहावे हे सांगते.

तलावाची विभागणी का करायची?

  • 安全 性परवानग्यांमधील संघर्ष टाळण्यासाठी वेगवेगळ्या साईट्ससाठी वेगवेगळे युझर्स वापरा.
  • 性能优化प्रत्येक पूलसाठी प्रक्रियांची संख्या स्वतंत्रपणे समायोजित केली जाऊ शकते, ज्यामुळे रहदारीच्या मागणीनुसार लवचिक बदल करता येतात.
  • अलगीकरणलॉग, त्रुटी आणि लिसनिंग ॲड्रेस हे सर्व वेगळे केले जातात, ज्यामुळे समस्यानिवारण सोपे होते.

उदाहरणार्थ, जरी www.conf क्रॅश झाले तरी, etufo.org.conf सामान्यपणे चालू राहील आणि संपूर्ण सर्व्हर बंद पाडणार नाही.

实际场景

  • सिंगल-साइट सर्व्हरwww.conf पुरेसे आहे.
  • मल्टीसाइट सर्व्हरप्रत्येक साइटची स्वतःची स्वतंत्र .conf फाइल असते, जसे की etufo.org.conf.
  • डमी.कॉन्फकेवळ संदर्भासाठी, शिफारस केलेली नाही.

कॉन्फिगरेशन तुलना

www.conf (डिफॉल्ट पूल)

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 5

etufo.org.conf (Custom Pool)

[etufo.org]
user = etufo
group = etufo
listen = /run/php/etufo.sock
pm = dynamic
pm.max_children = 20
access.log = /var/log/php-fpm/etufo.access.log

मुख्य फरक हे आहेत: वापरकर्त्याची ओळख, ऐकण्याचा पत्ता आणि प्रक्रियांची संख्या.

१. PHP-FPM प्रक्रिया पूल पॅरामीटर्स समायोजित करा

जर कॉन्फिगरेशन वापरत असेल तर dynamicही काही कामाच्या प्रक्रिया पूर्व-सुरू करण्याची आणि विनंतीच्या प्रमाणात त्यानुसार गतिमानपणे समायोजित करण्याची एक पद्धत आहे, जी विनंतीची मात्रा अचानक वाढल्यास जलद प्रतिसाद देऊ शकते.

विशिष्ट प्रमाणात ट्रॅफिक असलेल्या वेबसाइटसाठी, हे वापरण्याची शिफारस केली जाते pm = dynamicकारण ते विशिष्ट प्रमाणात निष्क्रिय प्रक्रिया राखू शकते आणि उच्च समवर्ती दरम्यान 500 त्रुटी टाळू शकते.

जेव्हा अॅक्सेस व्हॉल्यूम अत्यंत कमी असेल आणि मेमरी रिसोर्सेस कमी असतील तेव्हाच ते वापरण्याची शिफारस केली जाते. pm = ondemand संसाधने वाचवण्यासाठी.

सुचवले dynamic, आणि ऑप्टिमाइझ करा pm.max_children आणि इतर पॅरामीटर्स:

pm = dynamic
pm.max_children = 16  ; 根据服务器资源调整,建议值:CPU 核心数 × 2
pm.start_servers = 4   ; 初始进程数,建议设为 max_children × 25%
pm.min_spare_servers = 2  ; 最小空闲进程数
pm.max_spare_servers = 7  ; 最大空闲进程数
pm.max_requests = 3000    ; 每个子进程处理完 3000 个请求后自动重启
pm.process_idle_timeout = 10s  ; 空闲进程 10s 后自动退出

तुम्हाला ते असे का बदलायचे आहे?

  • pm = dynamic: मागणीनुसार विनंतीची वाट पाहणे टाळण्यासाठी प्रक्रिया अधिक लवचिकपणे वाटप करा;
  • pm.max_children = 16: खूप कमी प्रक्रियांमुळे होणाऱ्या ५०० त्रुटी टाळा;
  • pm.start_servers = 5: संथ प्रक्रिया सुरू होण्यापासून टाळा;
  • pm.max_requests = 3000:मेमरी लीक रोखणे, प्रक्रिया नियमितपणे रीसायकल करा.

२. दीर्घकालीन व्याप्ती टाळण्यासाठी PHP स्क्रिप्ट्सच्या अंमलबजावणीचा वेळ मर्यादित करा.

request_terminate_timeout = 30s  ; 超过 30s 的 PHP 脚本自动终止
php_admin_value[memory_limit] = 128M  ; 限制 PHP 进程最大内存占用

यामुळे जास्त CPU वापरणाऱ्या काही PHP स्क्रिप्ट्समुळे सर्व्हर क्रॅश होण्यापासून बचाव होतो.

सेव्ह केल्यानंतर, PHP प्रक्रिया पुन्हा सुरू करा:

sudo systemctl restart php8.3-fpm

व्हीपीएस कॉन्फिगरेशनच्या आधारावर PHP-FPM ऑप्टिमाइझ करा

व्हीपीएस कॉन्फिगरेशनचे उदाहरण:

  • वर्णन: व्हीपीएस ३ एनव्हीएमई
  • डिस्क स्पेस: 300 जीबी
  • सीपीयू कोर: ८
  • रॅम: 24 GB

तुमच्या व्हीपीएस कॉन्फिगरेशननुसार ( ८ सीपीयू कोर, २४ जीबी रॅम ), तुमच्या सर्व्हरची संसाधने पुरेशी आहेत. पीएचपी-एफपीएमसाठी, २४ जीबी रॅममुळे तुम्ही एकाच वेळी खूप जास्त प्रक्रिया कॉन्फिगर करू शकता.

उत्पादन वातावरणात, आम्ही सामान्यतः सिस्टम, अपाचे डेटाबेस (जसे की MySQL / MariaDB), आणि कॅशे (जसे की Redis / Memcached ) साठी पुरेशी मेमरी (उदा. 8GB-12GB) वाटप करतो, आणि उर्वरित 12GB-16GB मेमरी पूर्णपणे PHP-FPM साठी वाटप करतो.

प्रत्येक PHP प्रक्रियेसाठी सरासरी 40MB-60MB मेमरी वापर गृहीत धरल्यास , 1GB मेमरीमध्ये अंदाजे 16-25 प्रक्रिया चालवता येतात.

खाली तुमच्यासाठी खास तयार केलेले , उच्च-कॉन्करन्सी आणि उच्च-कार्यक्षमतेचे FPM कॉन्फिगरेशन दिले आहे, जे वर्डप्रेसची क्षमता मोठ्या प्रमाणात वाढवू शकते आणि ट्रॅफिकमध्ये अचानक वाढ झाल्यामुळे ते क्रॅश होण्यापासून रोखू शकते:

pm = dynamic

; 允许的最大 PHP 进程数(12GB 内存 / 40MB ≈ 300)
; 8核CPU搭配300个进程,可以轻松应对极高并发,且不至于让内存溢出
pm.max_children = 300

; 启动时创建的初始进程数(CPU核心数 * 4)
pm.start_servers = 32

; 维持的最小空闲进程数(服务器空闲时保留的进程,保证随时响应)
pm.min_spare_servers = 16

; 维持的最大空闲进程数(超过这个数量的空闲进程会被释放)
pm.max_spare_servers = 64

; 每个进程处理1000个请求后自动重启,高配置服务器可适当调大,有效防止WP插件内存泄露
pm.max_requests = 1000

; 单个请求最大执行时间,超时60秒强杀,防止死锁卡死
request_terminate_timeout = 60s

; 慢日志路径及触发阈值(请求超过5秒则记录,用于排查性能瓶颈)
slowlog = /var/log/php8.5-fpm.log.slow
request_slowlog_timeout = 5s

💡 ही रचना का?

  1. pm.max_children = 300हे एक मुख्य ऑप्टिमायझेशन आहे. २४ जीबी मेमरीसाठी ५० प्रोसेसेसचे तुमचे पूर्वीचे कॉन्फिगरेशन खूपच मर्यादित होते. जेव्हा ट्रॅफिकमध्ये अचानक वाढ होते (किंवा बॉट्समुळे बॅकग्राउंडमध्ये गोंधळ होतो), तेव्हा ५० प्रोसेसेसवर त्वरित ताण येतो, ज्यामुळे कनेक्शन टाइमआउट होतात. ही संख्या ३०० पर्यंत वाढवल्याने तुमच्या सर्व्हरची कॉनकरन्सी प्रोसेसिंग क्षमता अनेक पटींनी सुधारू शकते.
  2. pm.start_servers / `min_spare_serversतुमच्याकडे ८ सीपीयू कोर असल्यामुळे, तुम्ही मल्टी-कोरच्या फायद्याचा उपयोग करून सुरुवातीला आणि सामान्यतः अधिक निष्क्रिय प्रक्रिया चालू ठेवू शकता, जेणेकरून प्रक्रिया तयार होण्याची वाट न पाहता नवीन विनंत्या त्वरित उघडता येतील.
  3. pm.max_requests = 1000५०० वरून १००० पर्यंत वाढवा. तुमची मेमरी मोठी आहे आणि प्रोसेस वारंवार रीस्टार्ट करण्याची गरज नाही. १००० पर्यंत वाढवल्याने, प्रोसेस वारंवार नष्ट होण्यामुळे आणि तयार होण्यामुळे होणारा सीपीयूचा वापर कमी होऊ शकतो.

स्लो लॉग पहा:

tail -f /var/log/php8.5-fpm.log.slow
tail -f /var/log/php8.4-fpm.log.slow

बदल केल्यानंतर, ते बदल लागू होण्यासाठी PHP-FPM सेवा रीस्टार्ट करायला विसरू नका.

systemctl restart php8.5-fpm

कोणत्याही वेळी प्रगतीचा मागोवा ठेवण्यासाठी PHP-FPM स्थिती देखरेख सक्षम करा.

PHP-FPM प्रोसेस मॉनिटरिंग सक्षम केल्याने तुम्हाला कोणत्याही वेळी सक्रिय प्रोसेसची संख्या आणि रिक्वेस्ट वेटिंग स्टेटस पाहता येते , ज्यामुळे सर्व्हर ओव्हरलोड टाळता येतो.

php-fpm.conf यामध्ये जोडले:

pm.status_path = /status

मग, Nginx कॉन्फिगरेशन:

location /status {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    allow 127.0.0.1;
    deny all;
}

अशा प्रकारे, तुम्ही हे करू शकता http://yourdomain.com/status PHP-FPM कसे कार्य करते ते पहा!

समस्यांचे त्वरित निवारण करण्यासाठी PHP-FPM लॉग ऑप्टिमाइझ करा.

php-fpm.conf जोडणे:

php_admin_value[error_log] = /var/log/php-fpm/error.log
php_admin_value[log_errors] = On
php_admin_value[error_reporting] = E_ALL
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s  ; 执行超过 5s 的脚本记录到日志

अशाप्रकारे, जेव्हा जेव्हा ५०० एरर येते तेव्हा तुम्ही थेट लॉग पाहू शकता:

tail -f /var/log/php-fpm/error.log

PHP एरर नोंदवते का ते पहा, जसे की out of memory,script execution timeout थांबा

मेमरी लीक टाळण्यासाठी PHP-FPM नियमितपणे रीस्टार्ट करा.

पास करण्यास सक्षम cron दीर्घकाळ चालणाऱ्या प्रक्रिया टाळण्यासाठी नियमितपणे PHP-FPM रीस्टार्ट करामेमरी लीक.

crontab -e

दररोज पहाटे ३ वाजता PHP-FPM स्वयंचलितपणे रीस्टार्ट करण्यासाठी खालील शेड्यूल केलेले कार्य जोडा:

0 3 * * * /usr/sbin/service php8.5-fpm restart

समस्या कायम राहिली तर काय? पुढील ऑप्टिमायझेशन!

वरील सुधारणा केल्यानंतरही तुम्हाला अधूनमधून 500 त्रुटी येत असल्यास , तुम्ही पुढील सुधारणा करू शकता:

१. PHP अंमलबजावणी कार्यक्षमता सुधारण्यासाठी OPcache सक्षम करा.

जर OPcache अद्याप सक्षम केलेले नसेल, तर तुम्ही ते असे स्थापित करू शकता (उदाहरणार्थ उबंटू वापरून):

sudo apt install php8.5-opcache -y

नंतर संपादित करा php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.validate_timestamps=0
  • opcache.validate_timestamps=0
  • रिअल-टाइम डिटेक्शन अक्षम कराफाइल सिस्टम I/O कमी करा आणि कार्यक्षमता सुधारा.
  • मात्र, याचा अर्थ असा आहे की PHP फाईल्समध्ये बदल केल्यानंतर तुम्हाला मॅन्युअली कॅशे साफ करावा लागेल (PHP सेवा रीस्टार्ट करावी लागेल).

कॉन्फिगरेशनमध्ये बदल केल्यानंतर, बदल लागू होण्यासाठी तुम्हाला PHP सेवा रीस्टार्ट करणे आवश्यक आहे.

sudo systemctl restart php<版本>-fpm

परिणाम? PHP पेज एक्झिक्युशन स्पीडमध्ये खूप सुधारणा झाली आहे!

२. Nginx कॉन्फिगरेशन ऑप्टिमायझेशन

Nginx संबंधित पॅरामीटर्स वाजवी आहेत याची खात्री करा, जसे की fastcgi_read_timeout जास्त अंमलबजावणी वेळेमुळे Nginx द्वारे PHP स्क्रिप्ट्स बंद होऊ नयेत म्हणून ते योग्यरित्या समायोजित करा:

fastcgi_read_timeout 60s;
client_max_body_size 100M;

सारांश: PHP-FPM ऑप्टिमाइझ करा आणि वेबसाइट आता क्रॅश होणार नाही!

या ऑप्टिमायझेशननंतर आम्ही कोणते समायोजन केले आहेत?

✅ PHP-FPM प्रक्रिया पूल ऑप्टिमायझ करणे, वापरा ondemandआणि ऑप्टिमाइझ करा pm.max_children पॅरामीटर;
PHP स्क्रिप्ट्सच्या अंमलबजावणीच्या वेळेवर मर्यादा घालणे, दीर्घकालीन CPU व्याप टाळण्यासाठी;
PHP-FPM मॉनिटरिंग सक्षम करा, रिअल टाइममध्ये प्रक्रिया लोड पहा;
PHP-FPM लॉग ऑप्टिमायझ करणे, ५०० त्रुटींचे त्वरित निवारण करा;
PHP-FPM नियमितपणे रीस्टार्ट करा., मेमरी लीक रोखणे;
OPcache सक्षम करा, PHP अंमलबजावणी कार्यक्षमता सुधारणे;
Nginx कॉन्फिगरेशन ऑप्टिमायझ करणे, टाइमआउट समस्या टाळण्यासाठी.

या ऑप्टिमायझेशननंतर, PHP-FPM भार मोठ्या प्रमाणात कमी होईल आणि वेबसाइट ऑपरेशन अधिक स्थिर होईल! 🔥

आता प्रयत्न करून पहा! 💪🚀

जर तुम्हाला HestiaCP वापरून PHP-FPM टेम्पलेट्स कस्टमाइझ करण्याबद्दल अधिक जाणून घेण्याची उत्सुकता असेल, तर हा लेख तुम्हाला सखोल माहिती देईल:

👉 हेस्टियासीपी कस्टम पीएचपी-एफपीएम टेम्पलेट: पीएचपी ८.५ परफॉर्मन्स ऑप्टिमायझेशनची गुपिते ▼

या सामग्रीमध्ये तुम्हाला खालील गोष्टी दिसतील:

  • उच्च-समवर्ती ऑप्टिमायझेशन तंत्र: योग्य प्रक्रिया संरचनेद्वारे प्रतिसादाचा वेग कसा सुधारावा.
  • सुरक्षा विलगीकरण उपाय: क्रॉस-साइट ऍक्सेसचे धोके टाळा आणि खात्याची स्थिरता सुनिश्चित करा.
  • लॉग्स आणि मॉनिटरिंग: अडथळे शोधण्यासाठी आणि वेबसाइटची कार्यक्षमता सतत सुधारण्यासाठी स्लो लॉग्सचा वापर करा.

आशा आहे की, चेन वेइलियांगच्या ब्लॉगवर ( https://www.chenweiliang.com/ ) शेअर केलेला "HestiaCP PHP-FPM ओव्हरलोड? डायनॅमिक वेबपेज 500 एरर? ही ऑप्टिमायझेशन पद्धत त्वरित परिणाम देईल!" हा लेख तुम्हाला उपयुक्त ठरेल.

या लेखाची लिंक शेअर करण्यास हरकत नाही: https://www.chenweiliang.com/cwl-32512.html

अधिक लपलेल्या युक्त्या उघड करण्यासाठी🔑, आमच्या टेलिग्राम चॅनेलमध्ये सामील होण्यासाठी स्वागत आहे!

आवडल्यास शेअर आणि लाईक करा! तुमचे शेअर्स आणि लाईक्स ही आमची सतत प्रेरणा आहेत!

 

评论 评论

您的邮箱地址不会被公开。必填项已用*标注

Top स्क्रोल करा