ฉันไม่รู้จริงๆว่าเกิดอะไรขึ้นที่นี่ในขณะนี้:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1272 root 20 0 3829868 3.312g 1860 D 0.7 93.0 512:39.94 smbd
free -m
บอก:
total used free shared buffers cached
Mem: 3644 3560 84 7 0 25
-/+ buffers/cache: 3533 110 <--- this is what bugs me
Swap: 4292 2146 2146
คำจำกัดความบริการ:
[global]
server role = standalone server
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
[homes]
comment = Home Directories
valid users = %S
create mask = 0700
directory mask = 0700
browseable = No
[printers]
comment = All Printers
path = /var/spool/samba
create mask = 0700
printable = Yes
print ok = Yes
browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
#I don't really know what's this, but... it was a working share in its time
[media]
path = /rem/media/
[rem]
path = /rem/
force user = <rem owner username here>
read only = No
create mask = 0660
directory mask = 0770
แก้ไข:เริ่มsmbd
บริการใหม่ดูเหมือนว่าจะแก้ปัญหาแต่มันกลับมาประมาณ 2 ชั่วโมงหลังจากนั้น
แก้ไข 2:หลังจากปิดsmbd
บริการทุกอย่างดูเหมือนจะ OK:
total used free shared buffers cached
Mem: 3644 123 3521 8 3 36
-/+ buffers/cache: 83 3561
Swap: 4292 230 4062
EDIT3:นี่คือรายละเอียดเพิ่มเติม (ถามโดยDaniel B
):
- คำถามคือ: ทำไมแซมบ้ากิน ram มากขนาดนั้น
- Distro: debian ในกรณีที่คุณไม่สามารถอ่านแท็ก: P
- เวอร์ชัน:
4.2.10-Debian
- รูปแบบการเข้าถึง? ไม่มีความคิดว่าเป็น: หน้า
- ไฟล์ขนาดใหญ่: ไม่มากเพียง 2-3 ชิ้น ของไฟล์ 4GB ไฟล์ขนาดเล็ก: A LOT
EDIT4:ดูเหมือนว่าแซมบ้าจะไม่อ่าน / เขียนอะไรเลยในขณะที่กิน RAM:
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1351 be/4 root 0.00 B/s 3.95 K/s 0.00 % 0.00 % smbd -D
แก้ไข 5:ปัญหาแก้ไขได้ครึ่งโดยใช้Hastur
คำแนะนำของ ตอนนี้เรากำลังรอให้ลูกค้าดำเนินการต่อไปและทำดัชนี / สแกน / ทำอะไรกับแซมบ้าแบ่งปันสิ่งที่พวกเขาต้องการ
สถานะปัจจุบัน:
18992 root 20 0 283140 8916 6584 S 1.0 0.2 0:00.32 smbd
18983 root 20 0 284048 14964 11752 S 0.7 0.4 0:00.16 smbd
แก้ไข 6:น่าสนใจแค่ไหน:
18983 root 20 0 2964080 2.564g 6044 R 92.1 72.0 853:58.94 smbd
ตอนนี้มันใช้หน่วยความจำและ CPU มีคนช่วยด้วย! :)
EDIT7:เอาล่ะ จำกัด จำนวนการล็อกไฟล์และการเชื่อมต่อ แต่จะไม่มีการเปลี่ยนแปลง กินแรมของฉันอย่างบ้าคลั่ง! อย่างน้อยก็หยุดกิน CPU ทันที
24606 root 20 0 3768932 3.325g 2332 D 17.3 93.4 1441:50 smbd
ความช่วยเหลือใด ๆ ที่เป็นที่นิยมจริงๆ ฉันสนิทกับการเขียนงาน cron เริ่ม smbd ใหม่ทุก ๆ 24 ชั่วโมง
find . | wc -l
) มีจำนวนเท่าไหร่ในไดเรกทอรีเดียว? หากพวกเขามีมากเกินไปคุณสามารถแบ่งใน subpath เพิ่มเติม ...
find . | wc -l
: 24128
(ดำเนินการจากส่วนแบ่งการ samba ( /rem/
))