Medien Indizierung (Indexierung) wird mit "Out of memory" abgebrochen

[JoachimS]

Hi,
nach Upgrade meiner DS209 auf DSM 4.2 und Austausch einer 1,5TB disk mit einer 4TB disk wird die Medien Indizierung mit "Out of memory" abgebrochen.
Siehe mein Thread über Upgrade Strategie auf 3TB
DLNA geht dann nicht mehr, nach einem reboot startet die Indexierung wieder neu um dann wieder nach ca. 2 Tagen abzubrechen.
Leider habe ich nicht den kompletten log und mein syslog package hat noch nie entries angezeigt.
Habe jetzt den Support gefragt, hoffe die DS209 wird noch unterstützt.

Hier /var/log/messages, denke die synoindexd Fehler "Failed to av_open_input_file" führen nicht direkt zum Abbruch, sind ja 2 Tage früher.

Sep  9 01:46:33 synoindexd: parse_mediainfo.c (467) Failed to av_open_input_file() file [/volume2/photo/Family/Korb/Korb abfüllen/MVI_0095.avi].
>no entries / deleted

Sep 11 04:29:40 kernel: [196996.190000] Out of memory: kill process 11237 (httpd) score 1021 or a child
Sep 11 04:29:40 kernel: [196996.200000] Killed process 11237 (httpd)
Sep 11 04:29:40 kernel: [196996.210000] dovecot-auth invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 11 04:29:40 kernel: [196996.220000] [<c00f92ac>] (unwind_backtrace+0x0/0xe4) from [<c014d814>] (oom_kill_process+0x68/0x1cc)
Sep 11 04:29:40 kernel: [196996.230000] [<c014d814>] (oom_kill_process+0x68/0x1cc) from [<c014dd84>] (__out_of_memory+0x54/0xd8)
Sep 11 04:29:40 kernel: [196996.230000] [<c014dd84>] (__out_of_memory+0x54/0xd8) from [<c014de78>] (out_of_memory+0x70/0xa8)
Sep 11 04:29:40 kernel: [196996.240000] [<c014de78>] (out_of_memory+0x70/0xa8) from [<c015069c>] (__alloc_pages_nodemask+0x41c/0x4c8)
Sep 11 04:29:40 kernel: [196996.250000] [<c015069c>] (__alloc_pages_nodemask+0x41c/0x4c8) from [<c01526c8>] (__do_page_cache_readahead+0x94/0x1e4)
Sep 11 04:29:40 kernel: [196996.260000] [<c01526c8>] (__do_page_cache_readahead+0x94/0x1e4) from [<c0152848>] (ra_submit+0x30/0x38)
Sep 11 04:29:40 kernel: [196996.270000] [<c0152848>] (ra_submit+0x30/0x38) from [<c014c4f0>] (filemap_fault+0x1d0/0x3a8)
Sep 11 04:29:40 kernel: [196996.280000] [<c014c4f0>] (filemap_fault+0x1d0/0x3a8) from [<c015d9ec>] (__do_fault+0x54/0x3e0)
Sep 11 04:29:40 kernel: [196996.290000] [<c015d9ec>] (__do_fault+0x54/0x3e0) from [<c015ece4>] (handle_mm_fault+0x268/0x5b0)
Sep 11 04:29:40 kernel: [196996.300000] [<c015ece4>] (handle_mm_fault+0x268/0x5b0) from [<c00fa1ac>] (do_page_fault+0xe8/0x1dc)
Sep 11 04:29:40 kernel: [196996.310000] [<c00fa1ac>] (do_page_fault+0xe8/0x1dc) from [<c0027200>] (do_PrefetchAbort+0x40/0xa4)
Sep 11 04:29:40 kernel: [196996.320000] [<c0027200>] (do_PrefetchAbort+0x40/0xa4) from [<c002bec0>] (ret_from_exception+0x0/0x10)
Sep 11 04:29:40 kernel: [196996.330000] Exception stack(0xc8b4dfb0 to 0xc8b4dff8)
Sep 11 04:29:40 kernel: [196996.330000] dfa0:              00000001 00000006 00001388 00000000
Sep 11 04:29:40 kernel: [196996.340000] dfc0: 00000006 00056da8 000551a8 000000a8 00055e28 0004c964 00000000 bea7ca7c
Sep 11 04:29:40 kernel: [196996.350000] dfe0: 0000304c bea7ca38 0002ca10 4074bc4c 60000010 ffffffff
Sep 11 04:29:40 kernel: [196996.360000] Mem-info:
Sep 11 04:29:40 kernel: [196996.360000] Normal per-cpu:
Sep 11 04:29:40 kernel: [196996.360000] CPU    0: hi:   90, btch:  15 usd:  63
Sep 11 04:29:40 kernel: [196996.370000] active_anon:24665 inactive_anon:25216 isolated_anon:0
Sep 11 04:29:40 kernel: [196996.370000]  active_file:266 inactive_file:158 isolated_file:0
Sep 11 04:29:40 kernel: [196996.370000]  unevictable:0 dirty:0 writeback:0 unstable:0
Sep 11 04:29:40 kernel: [196996.370000]  free:2045 slab_reclaimable:608 slab_unreclaimable:4263
Sep 11 04:29:40 kernel: [196996.370000]  mapped:4915 shmem:6345 pagetables:866 bounce:0
Sep 11 04:29:40 kernel: [196996.380000] Normal free:8180kB min:8192kB low:12288kB high:20480kB active_anon:98660kB inactive_anon:100864kB active_file:1064kB inactive_file:632kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlo
Sep 11 04:29:40 kernel: [196996.390000] lowmem_reserve[]: 0 0
Sep 11 04:29:40 kernel: [196996.390000] Normal: 1*4kB 16*8kB 41*16kB 9*32kB 5*64kB 3*128kB 3*256kB 1*512kB 3*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB 0*65536kB 0*131072kB 0*262144kB 0*524288kB 0*1048576kB = 8180kB
Sep 11 04:29:40 kernel: [196996.410000] 9391 total pagecache pages
Sep 11 04:29:40 kernel: [196996.410000] 2622 pages in swap cache
Sep 11 04:29:40 kernel: [196996.420000] Swap cache stats: add 336130, delete 333508, find 1932294/1961223
Sep 11 04:29:40 kernel: [196996.420000] Free swap  = 0kB
Sep 11 04:29:40 kernel: [196996.430000] Total swap = 522040kB
Sep 11 04:29:40 kernel: [196996.430000] 65536 pages of RAM
Sep 11 04:29:40 kernel: [196996.440000] 2438 free pages
Sep 11 04:29:40 kernel: [196996.440000] 3292 reserved pages
Sep 11 04:29:40 kernel: [196996.440000] 4871 slab pages
Sep 11 04:29:40 kernel: [196996.450000] 12836 pages shared
Sep 11 04:29:40 kernel: [196996.450000] 2622 pages swap cached
Sep 11 04:29:40 kernel: [196996.450000] Out of memory: kill process 11371 (httpd) score 1021 or a child
Sep 11 04:29:40 kernel: [196996.460000] Killed process 11371 (httpd)
Sep 11 04:29:40 kernel: [196996.470000] dovecot-auth invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 11 04:29:40 kernel: [196996.480000] [<c00f92ac>] (unwind_backtrace+0x0/0xe4) from [<c014d814>] (oom_kill_process+0x68/0x1cc)
Sep 11 04:29:40 kernel: [196996.490000] [<c014d814>] (oom_kill_process+0x68/0x1cc) from [<c014dd84>] (__out_of_memory+0x54/0xd8)
Sep 11 04:29:40 kernel: [196996.490000] [<c014dd84>] (__out_of_memory+0x54/0xd8) from [<c014de78>] (out_of_memory+0x70/0xa8)
Sep 11 04:29:40 kernel: [196996.500000] [<c014de78>] (out_of_memory+0x70/0xa8) from [<c015069c>] (__alloc_pages_nodemask+0x41c/0x4c8)
Sep 11 04:29:40 kernel: [196996.510000] [<c015069c>] (__alloc_pages_nodemask+0x41c/0x4c8) from [<c01526c8>] (__do_page_cache_readahead+0x94/0x1e4)
Sep 11 04:29:40 kernel: [196996.520000] [<c01526c8>] (__do_page_cache_readahead+0x94/0x1e4) from [<c0152848>] (ra_submit+0x30/0x38)
Sep 11 04:29:40 kernel: [196996.530000] [<c0152848>] (ra_submit+0x30/0x38) from [<c014c4f0>] (filemap_fault+0x1d0/0x3a8)
Sep 11 04:29:40 kernel: [196996.540000] [<c014c4f0>] (filemap_fault+0x1d0/0x3a8) from [<c015d9ec>] (__do_fault+0x54/0x3e0)
Sep 11 04:29:40 kernel: [196996.550000] [<c015d9ec>] (__do_fault+0x54/0x3e0) from [<c015ece4>] (handle_mm_fault+0x268/0x5b0)
Sep 11 04:29:40 kernel: [196996.560000] [<c015ece4>] (handle_mm_fault+0x268/0x5b0) from [<c00fa1ac>] (do_page_fault+0xe8/0x1dc)
Sep 11 04:29:40 kernel: [196996.570000] [<c00fa1ac>] (do_page_fault+0xe8/0x1dc) from [<c0027200>] (do_PrefetchAbort+0x40/0xa4)
Sep 11 04:29:40 kernel: [196996.580000] [<c0027200>] (do_PrefetchAbort+0x40/0xa4) from [<c002bec0>] (ret_from_exception+0x0/0x10)
Sep 11 04:29:40 kernel: [196996.590000] Exception stack(0xc8b4dfb0 to 0xc8b4dff8)
Sep 11 04:29:40 kernel: [196996.590000] dfa0:              00000001 00000006 00001388 00000000
Sep 11 04:29:40 kernel: [196996.600000] dfc0: 00000006 00056da8 000551a8 000000a8 00055e28 0004c964 00000000 bea7ca7c
Sep 11 04:29:40 kernel: [196996.610000] dfe0: 0000304c bea7ca38 0002ca10 4074bc4c 60000010 ffffffff
Sep 11 04:29:40 kernel: [196996.620000] Mem-info:
Sep 11 04:29:40 kernel: [196996.620000] Normal per-cpu:
Sep 11 04:29:40 kernel: [196996.620000] CPU    0: hi:   90, btch:  15 usd:  14
Sep 11 04:29:40 kernel: [196996.630000] active_anon:24634 inactive_anon:25216 isolated_anon:0
Sep 11 04:29:40 kernel: [196996.630000]  active_file:266 inactive_file:158 isolated_file:0
Sep 11 04:29:40 kernel: [196996.630000]  unevictable:0 dirty:0 writeback:0 unstable:0
Sep 11 04:29:40 kernel: [196996.630000]  free:2034 slab_reclaimable:608 slab_unreclaimable:4263
Sep 11 04:29:40 kernel: [196996.630000]  mapped:4915 shmem:6345 pagetables:849 bounce:0
Sep 11 04:29:40 kernel: [196996.640000] Normal free:8136kB min:8192kB low:12288kB high:20480kB active_anon:98536kB inactive_anon:100864kB active_file:1064kB inactive_file:632kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlo
Sep 11 04:29:40 kernel: [196996.650000] lowmem_reserve[]: 0 0
Sep 11 04:29:40 kernel: [196996.650000] Normal: 2*4kB 8*8kB 42*16kB 9*32kB 5*64kB 3*128kB 3*256kB 1*512kB 3*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB 0*65536kB 0*131072kB 0*262144kB 0*524288kB 0*1048576kB = 8136kB
Sep 11 04:29:40 kernel: [196996.670000] 9391 total pagecache pages
Sep 11 04:29:40 kernel: [196996.670000] 2622 pages in swap cache
Sep 11 04:29:40 kernel: [196996.680000] Swap cache stats: add 336130, delete 333508, find 1932294/1961223
Sep 11 04:29:40 kernel: [196996.680000] Free swap  = 0kB
Sep 11 04:29:40 kernel: [196996.690000] Total swap = 522040kB
Sep 11 04:29:40 kernel: [196996.690000] 65536 pages of RAM
Sep 11 04:29:40 kernel: [196996.700000] 2375 free pages
Sep 11 04:29:40 kernel: [196996.700000] 3292 reserved pages
Sep 11 04:29:40 kernel: [196996.700000] 4871 slab pages
Sep 11 04:29:40 kernel: [196996.710000] 12818 pages shared
Sep 11 04:29:40 kernel: [196996.710000] 2622 pages swap cached
Sep 11 04:29:40 kernel: [196996.710000] Out of memory: kill process 11372 (httpd) score 1021 or a child
Sep 11 04:29:40 kernel: [196996.720000] Killed process 11372 (httpd)
Sep 11 04:29:40 kernel: [196996.840000] Out of memory: kill process 23884 (synoflvconv) score 705 or a child
Sep 11 04:29:40 kernel: [196996.840000] Killed process 23884 (synoflvconv)
Sep 11 04:29:40 kernel: [196997.150000] Out of memory: kill process 6361 (smbd) score 200 or a child
Sep 11 04:29:40 kernel: [196997.150000] Killed process 6377 (smbd)
Sep 11 04:29:40 kernel: [196997.490000] Out of memory: kill process 9102 (synoindexd) score 136 or a child
Sep 11 04:29:40 kernel: [196997.500000] Killed process 9102 (synoindexd)

 

[fbl1]

Bricht der immer beim gleichen File ab oder jedesmal bei einem anderen. Falls es immer das gleiche ist mal schauen ob es defekt ist bzw. zieh es mal runter damit es beim nächsten mal nicht mit indiziert wird.

 

[jahlives]

autsch, das schaut aus als wären sowohl RAM als auch Swap augegangen und irgendwann beginnt das System Prozesse zu killen damit wieder Speicher frei wird. Ich würde es mal mit weniger Mediendateien probieren ob dann der Index durchläuft

 

[JoachimS]

Danke für die schnellen Antworten, ja ich könnte einige der Medien Dateien verlagern, wenn ich nur wüsste wo er abbricht. Zeigt das das admin tool?
der Log ist doch etwas grösser, bevor synoindexd gekillt wird killt er mehrere Male SQL:

 cat /var/log/messages | grep index
Sep 11 04:29:40 kernel: [196997.490000] Out of memory: kill process 9102 (synoindexd) score 136 or a child
Sep 11 04:29:40 kernel: [196997.500000] Killed process 9102 (synoindexd)
Sep 11 15:30:06 kernel: [   18.230000]     o eth0, ifindex = 2, GbE port = 0
Sep 11 15:33:14 synoindexd: synoindexd.c:294 Bad format [008.jpg ].
NAS> cat /var/log/messages | grep sql
Sep 11 01:43:26 kernel: [187024.090000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.100000] Killed process 10946 (mysqld)
Sep 11 01:43:26 kernel: [187024.110000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.110000] Killed process 10946 (mysqld)
Sep 11 01:43:26 kernel: [187024.130000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.130000] Killed process 10946 (mysqld)
Sep 11 01:43:26 kernel: [187024.150000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.150000] Killed process 10946 (mysqld)
Sep 11 01:43:26 kernel: [187024.170000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.170000] Killed process 10946 (mysqld)
Sep 11 01:43:26 kernel: [187024.190000] Out of memory: kill process 5922 (mysqld_safe) score 304 or a child
Sep 11 01:43:26 kernel: [187024.190000] Killed process 10946 (mysqld)
Sep 11 01:43:57 kernel: [187056.280000] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 11 01:43:57 kernel: [187056.490000] Out of memory: kill process 11170 (mysqld) score 17936 or a child
Sep 11 01:43:57 kernel: [187056.490000] Killed process 11170 (mysqld)
Sep 11 15:32:03 logdispatchd: sqlite.c (105) Failed to connect to (null), user: (null), pass:xxx, db:/volume2/Joachim/.SYNOACCOUNTDB. (unable to open database file)

Ich beobachte mal den Speicherverbrauch. mySQL braucht 44%, es sind aber noch 13740K frei von 255MB (235516K used)

Mem: 235516K used, 13740K free, 0K shrd, 22052K buff, 100984K cached
CPU:  8.9% usr 36.4% sys 39.4% nic  3.9% idle 11.2% io  0.0% irq  0.0% sirq
Load average: 4.24 3.81 3.44 6/170 14742
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 9104     1 root     S N  32544 13.0 29.8 /usr/syno/bin/synomkthumbd
 9099     1 root     S N  57644 23.0  4.3 /usr/syno/sbin/synoindexd
18322  5893 admin    S    35136 14.0  3.5 postgres: admin photo [local] idle
 3668     1 root     S    17096  6.8  0.4 scemd
  444     2 root     SW       0  0.0  0.4 [kjournald]
 9298     1 root     S <  66032 26.4  0.2 /var/packages/AudioStation/target/sbin/synoaudiod
11284  6591 root     S    65464 26.1  0.2 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
11873  6591 root     S    65464 26.1  0.2 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
 7701 21471 root     R     5444  2.1  0.2 top
  343     2 root     SW       0  0.0  0.2 [md0_raid1]
 5991  5922 admin    S     108m 44.3  0.0 /usr/syno/mysql/libexec/mysqld --basedir=/usr/syno/mysql --datadir=/volume2/@database/mysql --user=admin --ma
17411     1 root     S    86976 34.7  0.0 /var/packages/MediaServer/target/sbin/dms
 9309     1 root     S <  80456 32.1  0.0 /var/packages/AudioStation/target/bin/pulseaudio
 7443  6591 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
 8809  6591 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
10050  6591 root     S    65456 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
13456  6591 root     S    65456 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
12482  6591 root     S    65456 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
 6591     1 root     S    65368 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
  676  6591 root     S    65368 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
18116     1 root     S    65108 26.0  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
27352 18116 nobody   S    65108 26.0  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
18185 18116 nobody   S    65108 26.0  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
18186 18116 nobody   S    65108 26.0  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
18187 18116 nobody   S    65108 26.0  0.0 /usr/syno/apache/bin/httpd -DHAVE_PHP
13296     1 root     S    62044 24.8  0.0 /var/packages/VideoStation/target/sbin/synovpcd
16876     1 root     S    51852 20.7  0.0 /var/packages/VPNCenter/target/sbin/vpnauthd
18257  5893 admin    S    34728 13.8  0.0 postgres: admin mediaserver [local] idle
 5896  5893 admin    S    33900 13.5  0.0 postgres: writer process
 5893     1 admin    S    33768 13.5  0.0 /usr/syno/pgsql/bin/postgres -D /var/services/pgsql --config_file=/usr/syno/pgsql/etc/postgresql.conf --hba_f
 5897  5893 admin    S    33768 13.5  0.0 postgres: wal writer process
 9110     1 root     S N  32764 13.1  0.0 /usr/syno/sbin/synomkflvd
13226     1 root     S N  32476 12.9  0.0 /var/packages/VideoStation/target/sbin/synovideometadatad
13156     1 root     S N  32464 12.9  0.0 /var/packages/VideoStation/target/sbin/synovideoindexd
14740 11284 root     R    27672 11.0  0.0 /usr/syno/synoman/webman/modules/ThumbConvertProgress/ThumbConvertProgress.cgi

lg
Joachim

 

[süno42]

Wie Jahlives schon erwähnt hatte, hat der OOM-Killer zugeschlagen. Du scheinst mindestens einen sehr speicherhungrigen Prozeß zu haben. Zumindest ging die Initiative von Dovecot aus. Probier mal die optimistische Speicherallozierung zu deaktiveren. Auf der Konsole hierfür folgenden Befehl ausführen:

echo 2 > /proc/sys/vm/overcommit_memory​

Dies verhindert, daß Anwendungen im System mehr Speicher anfordern können als physisch zzgl. Swap vorhanden ist. Dies schließt zwar nicht 100%tig aus, daß der OOM-Killer zuschlägt, aber reduziert dessen Wahrscheinlichkeit.


Viele Grüße
Süno42

 

[JoachimS]

Habe ich gemacht, muss ich dazu rebooten?
Wohl nicht, bekomme viele Fehler mit Cannot allocate memory

Sep 11 17:52:16 synomkthumbd: package.c:380 dlopen error: /usr/syno/etc/synoindex/packages/VideoStation/libvideoindex.so: failed to map segment from shared object: Cannot allocate memory
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Exif.GPSInfo.GPSLatitudeRef -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Xmp.dc.description -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Xmp.photoshop.headline -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Iptc.Application2.Caption -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Exif.Image.ImageDescription -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:277 Failed to pipe /usr/syno/bin/exiv2 -g Xmp.dc.subject -Pt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG"
Sep 11 17:52:16 synoindexd: photo_database.c:222 Failed to pipe /usr/syno/bin/exiv2 -pa "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG" | grep Iptc.Application2.Keywords
Sep 11 17:52:16 synoindexd: photo_database.c:388 Failed to pipe /usr/syno/bin/exiv2 -Pkt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG" | grep "Xmp.MP.RegionInfo/MPRI:Regions\["
Sep 11 17:52:16 synoindexd: photo_database.c:388 Failed to pipe /usr/syno/bin/exiv2 -Pkt "/volume2/photo/IBM/Abschiedswanderung_Walter/P1250530.JPG" | grep "Xmp.MP.RegionInfo/MPRI:Regions\["

Eine andere Eingrenzungsmöglichkeit wäre die Indizierungen getrennt für video, photo und music laufen zu lassen.

Update:
CPU ist jetzt fast 0, synoindexd und synomkthumbd sind zwar noch da tauchen aber in top nicht mehr auf

 

[jahlives]

ich glaube ehrlich gesagt nicht, dass bei diesem Fehlerbild eine bestimmte Mediendatei das problem ist. Das ist ein Problem des Systems an sich. Dir gehen die Ressourcen aus. Das kann daran liegen, dass dir erstmal der RAM ausgeht. Und wenn dann ein ausgelastetes System mit swappen beginnt ist sehr sehr schnell Schicht im Schacht. Denn der Swap liegt auf denselben Festplatten wie wo du die Mediendaten lesen/schreiben musst. Das schaukelt sich auf bis auch kein Swap mehr verfügbar ist, dann werden solange Prozesse gekillt bis entweder wieder Ressourcen da sind oder das System mit einem finalen Fehler tschüss sagt.
Gerade bei Bildern von Digicams mit Originalauflösung schiesst man sich ziemlich schnell den Speicher aus. Da kann z.B. helfen die Bilder erst am PC vor-zuskalieren. Mein Vorschlag: Originalbilder (volle Grösse) in eine eigene Freigabe welche NICHT indiziert wir. Am PC die Bilder vor dem Upload in die Medienverzeichnisse der DS skalieren. Habe bei mir jeweils längste Seite 1000px gemacht. Das kann den RAM-Verbrauch der Indizierung auf der DS um Faktoren senken.
Eine andere Idee wäre möglichst viele Prozesse zu stoppen, die für die Indizierung nicht notwendig sind. Dann hat die Indizierung wieder mehr RAM.

 

[süno42]

Habe ich gemacht, muss ich dazu rebooten?
Wohl nicht, bekomme viele Fehler mit Cannot allocate memory

Sep 11 17:52:16 synomkthumbd: package.c:380 dlopen error: /usr/syno/etc/synoindex/packages/VideoStation/libvideoindex.so: failed to map segment from shared object: Cannot allocate memory
[…]

Genau die Meldung hatte ich erwartet, allerdings nicht schon beim Start von synomkthumbd. Ich sehe jetzt gerade, daß Du nur 256MB Ram hast. Da heist es, während der Indizierung und Vorschaubildgenerierung nur minimale Anzahl von Hintergrundprozessen laufen lassen, alle anderen runterfahren. Danach kannst Du wieder wie gewohnt arbeiten.

Aber im allgemeinen solltest Du Dir mal Gedanken machen, ob Deine Anforderungen an Deine DS vielleicht nicht ein bißchen hoch sind.


Viele GRüße
Süno42

 

[JoachimS]

Gute Ideen,
habe mal fast alle packages gestopt und auch die Webstation disabled.
Allerdings ist httpd immer noch drin mit 26% 65K, und SQL mit 108M, frei sind jetzt 20M, hat also wenig gebracht.
SQL brauche ich ja für die Indizierung, wie bekomme ich httpd los?
Oder wie wäre es mit swap vergrössern?
An getrennte Ordner für Photo Station und Originalbilder (ich habe auch einige raws) habe ich auch schon gedacht, in meinem Falle sollten die Bilder aber schon HD sein, mein TV kann sogar zoomen, also Originalaufflösung wäre nett, aber man zoomt doch sehr selten.
Das Problem ist alle Bilder "in sync" zu halten: raw, hi-res JPG und photo station.

 

[JoachimS]

Ich gehe dann wieder auf
echo 1 > /proc/sys/vm/overcommit_memory
zurück. Ist automatisch nach dem Boot so.
Klar, ist nur eine DS209, ging aber seither sehr gut.
Ich warte auf die DSx14, evtl. mache ich einen Upgrade.

LG
Joachim

 

[jahlives]

swap vergrössern bringt rein gar nichts. Bestenfalls ein Pflaster ;-) Das liegt alles auf denselben Platten. Da würde es wahrscheinlich mehr bringen den swap komplett zu deaktivieren ;-)
raw Bilder auf jeden Fall in eine Freigabe welche der Index aussen vor lässt. Wenn du nicht auf 1000px willst sind sicher auch 2000px noch okay. Aber bei voller Grösse einer 10MP Kamera schiesst du dir den Speicher schneller aus als du Guten Tag sagen kannst ;-) Der Index nimmt pro Intervall jeweils mehrere Bilder d.h. dafür muss auch RAM vorhanden sein. Wenn die Bilder, welche der index gerade aktiv in Bearbeitung hat, geswappt werden ist es passiert. Von da an kann es nur noch bergab gehen.

 

[JoachimS]

raw habe ich separat, wie Du vorschlägst.
Viele Bilder haben ca. 8MB (nicht MP).
Im Admin tool sieht man, dass die Indexing Queue fast 20000 gross ist. Thumbs und FLV sind 0.
Freier RAM ist jetzt bei 15MB im top. Im DSM bei 51%. Wieso ist das unterschiedlich?
swap bei 4% von 510MB
Ich denke schon, dass swap was bringen kann, es können ja die inaktiven Prozesse geswapt werden.
Im DSM sieht der RAM Verbrauch noch nicht so bedrohlich aus wie im top:

 

[jahlives]

es gibt zwei grunsätzlich verschiedene Arten freien RAM darzustellen. Ein System wird freien RAM immer für Caching verwenden. Jetzt gibt es einmal die Anzeige für den freien RAM (inkl cache und buffer) und einmal exklusiv Cache und Buffer.
Das kann man z.B. beim free Kommando gut sehen (hier zwar keine DS aber das Prinzip ist dasselbe)

root@log1:~# free -m
             total       used       free     shared    buffers     cached
Mem:          8518       8152        366          0        442       7282
-/+ buffers/cache:        427       8090
Swap:         8191          0       8191

das System hat also 8.5GB RAM davon sind 8125MB "belegt" und 366MB "echt" frei. Die Zeile mit -+ gibt den freien RAM dann abzüglich Buffer und Cache aus. Also praktisch nichts wirklich von den Anwendungen belegt.

Aufgrund deiner Angaben vermute ich mal die 51% entsprechen der +- Zeile des free Kommandos.
top und htop rechnen jedoch den Cache/Buffer dazu

 

[JoachimS]

Danke für die Erklärung, die -/+ Zeile fehlt in der DS aber der DSM zeigt es an.
Inzwischen ist der RAM zu 52% ausgelastet und synoindexd ist von 55,6 auf 64,5MB angestiegen.
Es gab einige neue Fehler aber die sind nicht das Problem:

Sep 11 21:54:06 synoindexd: parse_mediainfo.c (467) Failed to av_open_input_file() file [/volume2/photo/Family/Korb/Korb abfüllen/MVI_0095.avi].
Sep 11 21:54:06 synoindexd: metamedia.c (216) Failed to parse misc media info from [/volume2/photo/Family/Korb/Korb abfüllen/MVI_0095.avi].

 

[JoachimS]

Update
synoindexd ist von 55,6 auf 64,5MB auf 72,2 angestiegen
Das sieht nach einem Memory Leak aus.

 

[jahlives]

nicht unbedingt ein Leak. Der Prozess kann z.B. mehr Memory wollen, weil er grössere Bilder zu bearbeiten hat oder er mehr Cache/Buffer nutzen muss, weil das System ausgelastet ist.

 

[JoachimS]

Update
Evtl. doch kein Leak
synoindexd ist von 55,6 auf 64,5MB auf 72,2 angestiegen und wieder auf 70 gefallen.
angestiegen sind die postgres, was machen die?
Im DSM ist der RAM Verbrauch auf 57% angestiegen.
Noch was, was ich stoppen kann? zB perl.

 

[jahlives]

postgres ist die DB für die Mediendateien.

 

[JoachimS]

Jetzt hat wieder Out of memory zugeschlagen.
synoindexd hat 128MB.
Im log sieht man, dass httpd mehrfach gekillt wurde.
Leider ist der Log voll. Gibt es ein Archive oder kann uch die Log Grösse einstellen?
Vor ca. 8H war die RAM Auslastung noch bei 58%
SWAP ist jetzt zu 100% voll!

Mem: 230932K used, 18324K free, 0K shrd, 2232K buff, 41680K cached
CPU:  1.5% usr 66.0% sys 17.6% nic  2.7% idle 11.9% io  0.0% irq  0.0% sirq
Load average: 3.88 6.17 5.33 2/107 25183
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
 6240     1 root     S N   633m259.5 27.5 /usr/syno/sbin/synoindexd
 9212  5892 admin    S    35140 14.0  0.9 postgres: admin photo [local] idle
 9211  5892 admin    S    34836 13.9  0.6 postgres: admin mediaserver [local] idle
  101     2 root     SW       0  0.0  0.2 [ata/0]
20009  6590 root     S    65472 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
21008  6590 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
23354  6590 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
23302  6590 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
23327  6590 root     S    65464 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
 6590     1 root     S    65368 26.1  0.0 /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/conf/httpd.conf-sys
11331  5892 admin    S    34732 13.8  0.0 postgres: admin video_metadata [local] idle
 5895  5892 admin    S    33892 13.5  0.0 postgres: writer process
 5892     1 admin    S    33768 13.5  0.0 /usr/syno/pgsql/bin/postgres -D /var/services/pgsql --config_file=/usr/syno/pgsql/etc/postgresql.conf --hba_file=/usr/sy
 5896  5892 admin    S    33768 13.5  0.0 postgres: wal writer process
 6245     1 root     S N  32336 12.9  0.0 /usr/syno/bin/synomkthumbd
 6524     1 root     S N  32328 12.9  0.0 /usr/syno/sbin/synomkflvd
 6376  6360 root     S    25756 10.3  0.0 /usr/syno/sbin/smbd -D
 6360     1 root     S    25664 10.2  0.0 /usr/syno/sbin/smbd -D
 6323     1 root     S    19212  7.6  0.0 /usr/syno/sbin/nmbd -D
 3668     1 root     S    17096  6.8  0.0 scemd
 8340     1 root     S    15412  6.1  0.0 /var/packages/SyslogServer/target/sbin/logdispatchd
 6386     1 root     S    14216  5.6  0.0 /usr/syno/sbin/afpd -g guest -c 256 -n NAS AFPServer -l default log_error
 5589     1 root     S    13980  5.5  0.0 /usr/syno/sbin/snmpd -Ln -c /usr/syno/etc/snmpd.conf -p /var/run/snmpd.pid udp:161,udp6:161,tcp:161,tcp6:161
 6627     1 root     S    13768  5.5  0.0 /usr/syno/apache/bin/httpd
24136  6627 nobody   S    13768  5.5  0.0 /usr/syno/apache/bin/httpd
24131  6627 nobody   S    13768  5.5  0.0 /usr/syno/apache/bin/httpd
24135  6627 nobody   S    13768  5.5  0.0 /usr/syno/apache/bin/httpd
 9151     1 root     S    13304  5.3  0.0 perl /usr/local/fhem2/bin/fhem.pl /usr/local/fhem2/log/fhem.cfg
 6230     1 root     S N  13024  5.2  0.0 /usr/syno/sbin/fileindexd
 6547     1 root     S    12644  5.0  0.0 /usr/syno/sbin/synosnmpcd

und free:

free
              total         used         free       shared      buffers
  Mem:       249256       232852        16404            0         3828
 Swap:       522040       522040            0
Total:       771296       754892        16404

 

[JoachimS]

synoindexd scheint in einer Schleife zu sein, es kommen dieselben Fehlermeldungen:

Sep 13 09:14:52 synoindexd: parse_mediainfo.c (467) Failed to av_open_input_file() file [/volume2/photo/Family/Korb/Korb abfüllen/MVI_0095.avi].
Sep 13 09:14:52 synoindexd: metamedia.c (216) Failed to parse misc media info from [/volume2/photo/Family/Korb/Korb abfüllen/MVI_0095.avi].

Ich habe synoindexd nicht neu gestartet, wie kann man elapsed oder start time herausfinden? ps -ef geht ja nicht in Busybox.
Ich überlege mir die Mediendateien separat zu indizieren.
Photo Station tut ja. Vermute der Fehler liegt da, evtl. ist doch eine raw Datei drin. Ic hkann auch den Ordner wie vorgeschlagen teilweise moven um ihn zu verkleinern
In der Video Station fehlen Ordner. Da ist indizieren am wichtigsten