root@tymin:/var/discourse# swapon
NAME TYPE SIZE USED PRIO
/dev/dm-0 partition 1.9G 1G -1
root@tymin:/var/discourse# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev devtmpfs 2008928 0 2008928 0% /dev
tmpfs tmpfs 404176 41336 362840 11% /run
/dev/mapper/VolGroup-root ext4 59629100 50018424 6991008 88% /
tmpfs tmpfs 2020876 0 2020876 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
tmpfs tmpfs 2020876 0 2020876 0% /sys/fs/cgroup
/dev/sda1 ext2 240972 226212 2319 99% /boot
tmpfs tmpfs 404172 0 404172 0% /run/user/1001
tmpfs tmpfs 404172 0 404172 0% /run/user/1000
/dev/loop0 btrfs 10485760 4250700 4424308 49% /chroot/compile
overlay overlay 59629100 50018424 6991008 88% /var/lib/docker/overlay2/4e9863e34f958e15f57c752fda2057b88f2aa03afaca82e0651f3aa23e56f795/merged
إعجاب واحد (1)
ما مقدار حركة المرور التي تحصل عليها؟ يبدو منتدى الخاص بك صغيرًا جدًا لمواجهة مشاكل كهذه.
هل هذا تثبيت رسمي؟ على أي نوع من الخوادم الافتراضية الخاصة يعمل منتدى الخاص بك؟
تقول صفحة المسؤول 50 ألف مشاهدة للصفحة في آخر 30 يومًا.
أعتقد ذلك؟ لقد اتبعت التعليمات التي استطعت العثور عليها في ذلك الوقت.
لم أقم بالكثير لتخصيص التثبيت.
لست متأكدًا. إنه خادم افتراضي ثنائي النواة بسعة 4 جيجابايت من cari.net.
لديك منتدى يعمل خلف nginx 1.10.3 وهو أقدم من 6 سنوات، لذا هناك شيء مريب هنا.
بصرف النظر عن ذلك، يجب أن يكون هذا أحد أسوأ تطبيقات Discourse أداءً التي رأيتها على الإطلاق. لا أريد الترويج لـ خدمة الاستضافة الخاصة بنا بحد ذاتها، ولكن هل فكرت يومًا في التبديل إلى مضيف آخر؟ يجب أن يعمل منتدى بهذا الحجم وحركة المرور بشكل جيد حتى على خادم صغير جدًا.
إعجاب واحد (1)
أنا متأكد من أن هناك الكثير لنتعلمه من معلومات miniprofiler التي شاركتها. هناك شيء واحد فقط يبرز الآن: هل لديك عدد هائل من المسودات؟
/my/activity/drafts
[quote=“Ed S, post:25, topic:260501, username:Ed_S”]هل لديك عدد هائل من المسودات؟
/my/activity/drafts
[/quote]
لدي 3 مسودات على ما يبدو.
إنه يعمل بنظام debian 9. 
يبدو أن nginx يعمل بشكل جيد، بقية موقعي (https://fredrik.hubbe.net/) ليس بطيئًا.
بأي مقياس إذن؟
هل يستهلك Discourse نفسه الكثير من الذاكرة أو الإدخال/الإخراج أو وحدة المعالجة المركزية؟ (إذا كان الأمر كذلك، فلماذا؟ لم أفعل شيئًا حيال ذلك حقًا…)
أم أن النظام بطيء؟ إذا كان الأمر كذلك، يمكنني مناقشة ذلك مع cari.net.
وسأحاول على الأرجح إعادة التشغيل هذه الليلة لمعرفة ما إذا كان ذلك سيساعد.
لقد مر عامان تقريبًا، أعتقد أنه قد حان الوقت؟
انتظر لحظة:
$ expr 0 `ps auxwww | tail +2 | awk '{ print " + " $6}'`
787952
إذا كان إجمالي الذاكرة المقيمة لجميع العمليات أقل من 800 ميجابايت، فما الذي تفعله بقية الذاكرة؟
لا يبدو أن /proc/meminfo مفيد جدًا أيضًا:
root@tymin:/# cat /proc/meminfo
MemTotal: 4041756 kB
MemFree: 122852 kB
MemAvailable: 53388 kB
Buffers: 15300 kB
Cached: 87636 kB
SwapCached: 125192 kB
Active: 314348 kB
Inactive: 300988 kB
Active(anon): 270652 kB
Inactive(anon): 276288 kB
Active(file): 43696 kB
Inactive(file): 24700 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1949692 kB
SwapFree: 921348 kB
Dirty: 144 kB
Writeback: 0 kB
AnonPages: 484704 kB
Mapped: 72596 kB
Shmem: 34520 kB
Slab: 319792 kB
SReclaimable: 26836 kB
SUnreclaim: 292956 kB
KernelStack: 6272 kB
PageTables: 19484 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3970568 kB
Committed_AS: 4146996 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4001728 kB
DirectMap2M: 192512 kB
ربما أحتاج إلى إعادة التشغيل أكثر مما أعتقد… تسرب ذاكرة نواة لمدة عامين؟
3 إعجابات
تمت إعادة التشغيل، ولدي الآن 2 جيجابايت من الذاكرة المجانية.
سنرى ما إذا كان ذلك سيستمر.
3 إعجابات
بعد استخدام Discourse لفترة، ستجد أن مساحة القرص الصلب كبيرة جدًا.
ويرجع ذلك أساسًا إلى مشكلة صور Docker، فكلما زادت الترقيات، زادت المساحة التي تشغلها.
قم بتشغيل الأمر التالي:
./launcher cleanup
يمكن أن يساعدك ذلك في تنظيف المساحة التي يشغلها Discourse.
سيساعد ذلك في استخدام مساحة القرص، ولكن للأسف في هذه الحالة:
هناك الكثير من التبديل (swapping) يحدث مما يقتل الأداء.
كل شيء ينتظر القرص، وهي حالة سيئة للغاية.
إعجاب واحد (1)
لا يتعلق الأمر بعدم العمل بشكل جيد، بالنسبة لي كان مؤشرًا على أن شيئًا ما قد يكون قديمًا أو ليس تثبيتًا قياسيًا.
يبدو أن إعادة التشغيل تعمل حتى الآن.
لا يزال غير متأكد من السبب.
يسرني أن إعادة التشغيل قد ساعدت!
قد يتضح أنه مفيد. سأشارك معلوماتي، لنظام أصغر بكثير.
ولكن إليك فكرة، إعداد نواة يمكن أن يؤثر على الأداء، هل لديك صفحات ضخمة شفافة ممكّنة؟ أنا لا أملكها:
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
راجع MKJ’s Opinionated Discourse Deployment Configuration للحصول على المشورة!
إليك معلومات الذاكرة الخاصة بي، على نظام أصغر بكثير يعمل بشكل جيد:
# cat /proc/meminfo
MemTotal: 1009140 kB
MemFree: 91888 kB
MemAvailable: 88692 kB
Buffers: 7644 kB
Cached: 137040 kB
SwapCached: 144884 kB
Active: 418972 kB
Inactive: 380324 kB
Active(anon): 345300 kB
Inactive(anon): 345852 kB
Active(file): 73672 kB
Inactive(file): 34472 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 2097144 kB
SwapFree: 1049764 kB
Dirty: 400 kB
Writeback: 0 kB
AnonPages: 620688 kB
Mapped: 67192 kB
Shmem: 36536 kB
Slab: 67768 kB
SReclaimable: 27832 kB
SUnreclaim: 39936 kB
KernelStack: 3804 kB
PageTables: 14968 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2601712 kB
Committed_AS: 3784772 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 460652 kB
DirectMap2M: 587776 kB
حسنًا، أردت فقط أن أغلق هذا الموضوع.
إعادة التشغيل ساعدت، وما زالت تساعد.
لا أعرف ما الذي تسبب في تسرب الذاكرة، وما لم يتغير شيء، فمن المحتمل أن أحتاج إلى إعادة التشغيل مرة أخرى مرة واحدة سنويًا تقريبًا، وهو ما يمكنني التعايش معه.
إعجاب واحد (1)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.