Olağandışı yüksek dentry önbellek kullanımı


34

Sorun

Çekirdek 2.6.32 ve 128 GB fiziksel RAM'e sahip bir CentOS makinesi birkaç gün önce başını belaya soktu. Sorumlu sistem yöneticisi, PHP-FPM uygulamasının, takas nedeniyle artık taleplere zamanında cevap vermediğini ve freeneredeyse hiç bellek kalmamış olduğunu gördükten sonra, makineyi yeniden başlatmayı seçtiğini söyledi.

Boş hafızanın Linux'ta kafa karıştırıcı bir kavram olabileceğini ve belki de yeniden başlatmanın yanlış bir şey olduğunu biliyorum. Ancak, söz konusu yönetici PHP uygulamasını (sorumlu olduğum) sorumlu tutuyor ve daha fazla araştırma yapmayı reddediyor.

Tek başıma öğrenebileceğim şey şu:

  • Yeniden başlatmadan önce boş hafıza (tamponlar ve önbellek dahil) sadece birkaç yüz MB idi.
  • Yeniden başlatmadan önce, /proc/meminfoyaklaşık 90 GB (evet, GB) civarında Slab bellek kullanımı bildirildi.
  • Yeniden başlattıktan sonra, boş hafıza 119 GB'dı, bir saat içinde 100 GB'a düşüyordu, çünkü PHP-FPM işçileri (yaklaşık 600 tanesi) hayatlarına geri dönüyordu; RES sütunu üsttedir (aylardır bu şekilde olmuştur ve PHP uygulamasının niteliği göz önüne alındığında mükemmel şekilde uygundur). Sıradışı veya kayda değer miktarda RAM tüketen işlem listesinde başka hiçbir şey yoktur.
  • Yeniden başlattıktan sonra Slab hafızası 300 MB civarındaydı.

O zamandan beri sistemi izliyorsanız ve en önemlisi, Slab hafızası, günde yaklaşık 5 GB'lık bir düz çizgi şeklinde artmaktadır. Tarafından bildirilen boş bellek freeve /proc/meminfoaynı oranda azalır. Slab şu anda 46 GB'da. Girişlere göre slabtopçoğuna göre kullanılır dentry:

Boş hafıza:

free -m
             total       used       free     shared    buffers     cached
Mem:        129048      76435      52612          0        144       7675
-/+ buffers/cache:      68615      60432
Swap:         8191          0       8191

meminfo:

cat /proc/meminfo
MemTotal:       132145324 kB
MemFree:        53620068 kB
Buffers:          147760 kB
Cached:          8239072 kB
SwapCached:            0 kB
Active:         20300940 kB
Inactive:        6512716 kB
Active(anon):   18408460 kB
Inactive(anon):    24736 kB
Active(file):    1892480 kB
Inactive(file):  6487980 kB
Unevictable:        8608 kB
Mlocked:            8608 kB
SwapTotal:       8388600 kB
SwapFree:        8388600 kB
Dirty:             11416 kB
Writeback:             0 kB
AnonPages:      18436224 kB
Mapped:            94536 kB
Shmem:              6364 kB
Slab:           46240380 kB
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB
KernelStack:        9336 kB
PageTables:       457516 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    72364108 kB
Committed_AS:   22305444 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      480164 kB
VmallocChunk:   34290830848 kB
HardwareCorrupted:     0 kB
AnonHugePages:  12216320 kB
HugePages_Total:    2048
HugePages_Free:     2048
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5604 kB
DirectMap2M:     2078720 kB
DirectMap1G:    132120576 kB

Slabtop:

slabtop --once
Active / Total Objects (% used)    : 225920064 / 226193412 (99.9%)
 Active / Total Slabs (% used)      : 11556364 / 11556415 (100.0%)
 Active / Total Caches (% used)     : 110 / 194 (56.7%)
 Active / Total Size (% used)       : 43278793.73K / 43315465.42K (99.9%)
 Minimum / Average / Maximum Object : 0.02K / 0.19K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
221416340 221416039   3%    0.19K 11070817       20  44283268K dentry                 
1123443 1122739  99%    0.41K 124827        9    499308K fuse_request           
1122320 1122180  99%    0.75K 224464        5    897856K fuse_inode             
761539 754272  99%    0.20K  40081       19    160324K vm_area_struct         
437858 223259  50%    0.10K  11834       37     47336K buffer_head            
353353 347519  98%    0.05K   4589       77     18356K anon_vma_chain         
325090 324190  99%    0.06K   5510       59     22040K size-64                
146272 145422  99%    0.03K   1306      112      5224K size-32                
137625 137614  99%    1.02K  45875        3    183500K nfs_inode_cache        
128800 118407  91%    0.04K   1400       92      5600K anon_vma               
 59101  46853  79%    0.55K   8443        7     33772K radix_tree_node        
 52620  52009  98%    0.12K   1754       30      7016K size-128               
 19359  19253  99%    0.14K    717       27      2868K sysfs_dir_cache        
 10240   7746  75%    0.19K    512       20      2048K filp  

VFS önbellek basıncı:

cat /proc/sys/vm/vfs_cache_pressure
125

Swappiness:

cat /proc/sys/vm/swappiness
0

Kullanılmayan hafızanın boşa harcandığını biliyorum, bu nedenle mutlaka kötü bir şey olmamalı (özellikle 44 GB'nin SReclaimable olduğu gösteriliyorsa). Ancak, görünüşe göre, makine yine de sorunlar yaşadı ve Slab’in 90 GB’yi aştığında birkaç gün içinde aynı şeylerin tekrar yaşanmasından korkuyorum.

Sorular

Bu sorularım var:

  • Slab hafızasının her zaman fiziksel RAM olduğunu ve sayının MemFree değerinden zaten çıkarıldığını düşünmekte yanlış mıyım?
  • Bu kadar yüksek sayıda dentry girişi normal midir? PHP uygulaması yaklaşık 1,5 M dosyaya erişebiliyor, ancak çoğu arşivde ve düzenli web trafiği için hiçbir zaman erişilemiyor.
  • Önbelleğe alınan inode sayısının önbellek sayısına göre çok daha düşük olduğu gerçeği için bir açıklama olabilir, bir şekilde ilişkilendirilmemeleri gerekir mi?
  • Sistem hafıza sorunuyla karşılaşırsa, çekirdek bazı dişlileri otomatik olarak serbest bırakmaz mı? Bunun olmamasının bir nedeni ne olabilir?
  • Tüm bu hafızanın ne olduğunu görmek için dişçi önbelleğini "incelemenin" herhangi bir yolu var mı (yani önbellekte saklanan yollar nelerdir)? Belki de bu bir çeşit bellek sızıntısına, sembolik bağ döngüsüne veya gerçekten PHP uygulamasının yanlış yaptığı bir şeye işaret eder.
  • PHP uygulama kodu ve tüm varlık dosyaları GlusterFS ağ dosya sistemi aracılığıyla monte edilir, bununla bir ilgisi olabilir mi?

Lütfen root olarak, sadece normal bir kullanıcı olarak araştırma yapamayacağımı ve yöneticinin yardım etmeyi reddettiğini unutmayın. echo 2 > /proc/sys/vm/drop_cachesSlab hafızasının gerçekten geri çağrılabilir olup olmadığını görmek için tipik bir testi bile yapmıyor .

Neler olup bittiğini ve daha fazlasını nasıl araştırabileceğime dair içgörü çok takdir edilecektir.

Güncellemeler

Bazı ileri tanı bilgileri:

Bağlantılar:

cat /proc/self/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=66063000k,nr_inodes=16515750,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/mapper/sysvg-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0
tmpfs /phptmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
tmpfs /wsdltmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0
/etc/glusterfs/glusterfs-www.vol /var/www fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
/etc/glusterfs/glusterfs-upload.vol /var/upload fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
172.17.39.78:/www /data/www nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78 0 0

Bilgi bağla:

cat /proc/self/mountinfo
16 21 0:3 / /proc rw,relatime - proc proc rw
17 21 0:0 / /sys rw,relatime - sysfs sysfs rw
18 21 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=66063000k,nr_inodes=16515750,mode=755
19 18 0:11 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
20 18 0:16 / /dev/shm rw,relatime - tmpfs tmpfs rw
21 1 253:1 / / rw,relatime - ext4 /dev/mapper/sysvg-lv_root rw,barrier=1,data=ordered
22 16 0:15 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw
23 21 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,barrier=1,data=ordered
24 21 0:17 / /phptmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
25 21 0:18 / /wsdltmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
26 16 0:19 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw
27 21 0:20 / /cgroup/cpuset rw,relatime - cgroup cgroup rw,cpuset
28 21 0:21 / /cgroup/cpu rw,relatime - cgroup cgroup rw,cpu
29 21 0:22 / /cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct
30 21 0:23 / /cgroup/memory rw,relatime - cgroup cgroup rw,memory
31 21 0:24 / /cgroup/devices rw,relatime - cgroup cgroup rw,devices
32 21 0:25 / /cgroup/freezer rw,relatime - cgroup cgroup rw,freezer
33 21 0:26 / /cgroup/net_cls rw,relatime - cgroup cgroup rw,net_cls
34 21 0:27 / /cgroup/blkio rw,relatime - cgroup cgroup rw,blkio
35 21 0:28 / /var/www rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-www.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
36 21 0:29 / /var/upload rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-upload.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
37 21 0:30 / /var/lib/nfs/rpc_pipefs rw,relatime - rpc_pipefs sunrpc rw
39 21 0:31 / /data/www rw,relatime - nfs 172.17.39.78:/www rw,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78

GlusterFS yapılandırması:

cat /etc/glusterfs/glusterfs-www.vol
volume remote1
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.71
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
    # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote2
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.72
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote3
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.73
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote4
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.74
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume replicate1
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote1 remote2
end-volume

volume replicate2
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote3 remote4
end-volume

volume distribute
  type cluster/distribute
  subvolumes replicate1 replicate2
end-volume

volume iocache
  type performance/io-cache
   option cache-size 8192MB        # default is 32MB
   subvolumes distribute
end-volume

volume writeback
  type performance/write-behind
  option cache-size 1024MB
  option window-size 1MB
  subvolumes iocache
end-volume

### Add io-threads for parallel requisitions
volume iothreads
  type performance/io-threads
  option thread-count 64 # default is 16
  subvolumes writeback
end-volume

volume ra
  type performance/read-ahead
  option page-size 2MB
  option page-count 16
  option force-atime-update no
  subvolumes iothreads
end-volume

Lütfen çıktısını cat /proc/self/mountsve (belki oldukça uzun) veriniz cat /proc/self/mountinfo.
Matthew Ife,

@ IMFE Soruyu güncelledim, her iki çıktı da eklendi.
Wolfgang Stengel

Buradaki hislerim muhtemelen NFS takma dişi önbelleğe alma ile ilgili. İlgi alanı dışında koşabilirsin cat /etc/nfsmount.conf. Ayrıca kendi dizininde çok sayıda dosya içeren herhangi bir dizininiz var mı?
Matthew Ife,

1
Peki, vfs_cache_pressure> 100 olduğundan, çekirdek dentrie önbellek hafızasını geri kazanmayı tercih etmelidir. Bu kolayca bir hata olabilir, 2.6.32, RedHat sırt yamalarında bile eski bir çekirdektir. Btw, tam çekirdek sürümü nedir?
poige

2
(Sysadmin'in kulağa korkunç geliyor . Bize kötü bir isim veriyor)
yine de

Yanıtlar:


14

Slab hafızasının her zaman fiziksel RAM olduğunu ve sayının MemFree değerinden zaten çıkarıldığını düşünmekte yanlış mıyım?

Evet.

Bu kadar yüksek sayıda dentry girişi normal midir? PHP uygulaması yaklaşık 1,5 M dosyaya erişebiliyor, ancak çoğu arşivde ve düzenli web trafiği için hiçbir zaman erişilemiyor.

Evet, sistem bellek baskısı altında değilse. Belleği bir şey için kullanmak zorundadır ve kendi kullanım şeklinizde, bu belleği kullanmanın en iyi yolu bu olabilir.

Önbelleğe alınan inode sayısının önbellek sayısına göre çok daha düşük olduğu gerçeği için bir açıklama olabilir, bir şekilde ilişkilendirilmemeleri gerekir mi?

Dizin işlemlerinin çoğu en olası açıklama olacaktır.

Sistem hafıza sorunuyla karşılaşırsa, çekirdek bazı dişlileri otomatik olarak serbest bırakmaz mı? Bunun olmamasının bir nedeni ne olabilir?

Olmalı ve yapmaması için hiçbir sebep düşünemiyorum. Bunun gerçekten yanlış giden şey olduğuna ikna olmadım. Çekirdeğinizi yükseltmenizi veya vfs_cache_pressure'ı daha da arttırmanızı şiddetle tavsiye ederim.

Tüm bu hafızanın ne olduğunu görmek için dişçi önbelleğini "incelemenin" herhangi bir yolu var mı (yani önbellekte saklanan yollar nelerdir)? Belki de bu bir çeşit bellek sızıntısına, sembolik bağ döngüsüne veya gerçekten PHP uygulamasının yanlış yaptığı bir şeye işaret eder.

Var olduğuna inanmıyorum. Çok fazla sayıda giriş yapan veya aranan veya gezilen çok derin dizin yapıları olan herhangi bir dizini arardım.

PHP uygulama kodu ve tüm varlık dosyaları GlusterFS ağ dosya sistemi aracılığıyla monte edilir, bununla bir ilgisi olabilir mi?

Kesinlikle bir dosya sistemi sorunu olabilir. Örneğin, dişçilerin serbest bırakılmamasına neden olan bir dosya sistemi hatası bir olasılıktır.


Sorularıma ayrı ayrı cevap verdiğiniz için teşekkür ederim. Önbellek basıncı nihayet daha da artmış ve dentry önbellek artışı durmuştur.
Wolfgang Stengel

Sorumlu programı henüz bulamadım. Daha fazlasını öğrenirsem, bu sorunu yaşayan başkalarına rapor vereceğim.
Wolfgang Stengel

1
Teşekkürler! Büyük dizin (0.25 mil dosya) tamamen benim durumumdaki sorunun nedeniydi, onunla etkileşime giren herhangi bir şey 2GB koç tarafından önbellekte kaybolurdu.
Bazı Linux Nerd

20

Onaylandı Çözüm

Aynı problemi yaşayabilenlere. Veri merkezi çalışanları nihayet bugün anladı. Suçlu, Libcurl ile birlikte gelen bir NSS (Ağ Güvenliği Hizmetleri) kütüphanesiydi. En yeni sürüme yükseltme yapmak sorunu çözdü.

Ayrıntıları açıklayan bir hata raporu burada:

https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1044666

Görünüşe göre, bir yolun yerel mi yoksa bir ağ sürücüsünde mi olduğunu belirlemek için, NSS varolmayan bir dosya arıyor ve dosya sisteminin geri bildirmesi için geçen süreyi ölçüyordu! Yeterli sayıda Curl isteğiniz ve yeterli belleğiniz varsa, bu isteklerin tümü önbelleğe alınır ve istiflenir.


15

Bu konuyla tam olarak karşılaştım ve Wolfgang sebebi konusunda haklı olsa da, bazı önemli detaylar eksik.

  • Bu sorun, curl veya libcurl ile yapılan SSL isteklerini veya güvenli bağlantı için mozilla NSS kullanan diğer yazılımları etkiler. Güvenli olmayan istekler sorunu tetiklemez.

  • Problem eşzamanlı kıvrılma istekleri gerektirmez. Dişçi birikimi, kıvrılma çağrıları, İşletim Sisteminin RAM'i geri alma çabalarını geçersiz kılacak kadar sık ​​olduğu sürece gerçekleşecektir.

  • NSS'nin yeni sürümü, 3.16.0, bunun için bir düzeltme içeriyor. ancak, NSS'yi yükselterek ücretsiz düzeltme alamazsınız ve NSS'nin tamamını yükseltmeniz gerekmez. minimum nss-softokn’u (nss-utils için gerekli bir bağımlılığa sahip) yükseltmeniz gerekir. ve bundan faydalanmak için, libcurl kullanan işlem için NSS_SDB_USE_CACHE ortam değişkenini ayarlamanız gerekir. Bu ortam değişkeninin varlığı, pahalı olmayan dosya kontrollerinin atlanmasına izin veren şeydir.

FWIW, herhangi birinin ihtiyacı olması durumunda biraz daha fazla bilgi / ayrıntı içeren bir blog yazısı yazdım .


Güzel bir blog yazısı için teşekkürler, ancak nss-softokn’un hala CentOS / RHEL’deki 3.16 sürümüne güncellenmediğini belirtmek isterim. Muhtemelen 6.6 versiyonunda düzeltilecektir.
Strahinja Kustudic

1
Not için teşekkürler. Belki Amazon, yönetilen depoları için bunun önüne geçti (belki bizim isteğimiz üzerine bile?). Daha eski sürümlerde (3.14-3.15), uygun ortam değişkenlerini ayarlayarak kazancınızın yarısını hala alırsınız. Bilgi birikiminiz varsa, doğrudan v3.16'yı oluşturabilirsiniz. Aksi takdirde, önbellek basıncını arttırmak ve ilişkili CPU isabetini almak, güvenilir performans için en iyi bahis olabilir.
J. Paulding

3
Bu, Centos 6.6'da nss-softokn-3.14.3-17 ile sabitlenmiştir
Strahinja Kustudic

1
Sadece hızlı bir düzeltme isteyen kişiler için açık olmak: Her ikisine de güncellemesine sahip nss-softokenRPM VE set NSS_SDB_USE_CACHE=YESbukle https için env Var sizin dentry önbelleği sel durdurma çağırır.
Steve Kehlet

4

Bkz https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch

Vfs_cache_pressure 100'den yüksek bir değere ayarlandığında, gözle görülür bazı dentry belleği geri kazanmasını beklediğinizi gösteren rakamlar var. Bu yüzden, 125'iniz sizin durumunuzda gerçekleşemeyecek kadar düşük olabilir.


Bütün itibaren artan okudum vfs_cache_pressureyukarıda 100alıdığınız için yeterli RAM yoksa sadece mantıklı. Bu durumda, 100'ün üzerinde bir değere sahip olmak (örneğin 10000) bir miktar RAM'i serbest bırakacaktır. Bu olsa, genel olarak daha kötü IO ile sonuçlanacaktır.
Mikko Rantalainen

3

Cevabınıza gerçekten bir açıklama değil, bu sistemin bir kullanıcısı olarak verdiğiniz bu bilgiler:

cat /proc/meminfo
MemTotal:       132145324 kB
...
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB

Bana bunun senin sorunun olmadığını ve yeterli bir açıklama sağlamak için sysadmin'in sorumluluğunu vermediğini söylemek yeterli.

Burada kaba görünmek istemiyorum ama;

  • Bu konağın rolü hakkında belirli bir bilginiz yok.
  • Ev sahibinin kaynakları nasıl önceliklendirmesi gerektiği, sizin kapsamınız dışında.
  • Bu ana bilgisayardaki depolamanın tasarımında ve dağıtımında tanıdık değil veya herhangi bir parçanız bulunmuyor.
  • Kök olmadığınız için belirli sistem çıktısını öneremezsiniz.

Döşeme tahsis anomalisini haklılaştırmak veya çözmek sizin sistem yöneticilerinin sorumluluğundadır . Ya sizi bu konuda yönlendiren (açıkçası ilgilenmiyorum) bütün destanın tam bir resmini vermediniz ya da sistem yöneticiniz bu sorunu ele almayı düşündüğü şekilde sorumsuzca ve / veya beceriksiz davranıyor.

İnternette rastgele bir yabancıya söylemekten çekinmeyin, sorumluluklarını ciddiye almadığını düşünüyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.