BillB66 Posted February 4, 2018 Posted February 4, 2018 **Solved: SSL connection to ISY was causing the memory leak** Seeing 2 sets of odd behavior that I am having a hard time trouble shooting. On my Pi I am seeing the mono process being killed and recycled due to running OOM. It also starts having trouble talking to ISY before the recycle. The pattern is repeated in the logs. <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858937] kthreadd invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), nodemask=0, order=1, oom_score_adj=0 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858955] CPU: 2 PID: 2 Comm: kthreadd Not tainted 4.9.59-v7+ #1047 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858957] Hardware name: BCM2835 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858977] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858987] [<8010c058>] (show_stack) from [<80456764>] (dump_stack+0xd4/0x118) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.858997] [<80456764>] (dump_stack) from [<8026d2ac>] (dump_header+0x9c/0x1f4) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859007] [<8026d2ac>] (dump_header) from [<80210b14>] (oom_kill_process+0x3e0/0x4e4) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859016] [<80210b14>] (oom_kill_process) from [<80210f7c>] (out_of_memory+0x124/0x334) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859025] [<80210f7c>] (out_of_memory) from [<80216120>] (__alloc_pages_nodemask+0xd7c/0xe58) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859036] [<80216120>] (__alloc_pages_nodemask) from [<8011ab38>] (copy_process.part.5+0xec/0x17b0) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859045] [<8011ab38>] (copy_process.part.5) from [<8011c38c>] (_do_fork+0xc8/0x408) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859053] [<8011c38c>] (_do_fork) from [<8011c73c>] (kernel_thread+0x40/0x48) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859062] [<8011c73c>] (kernel_thread) from [<8013d9a8>] (kthreadd+0x1e0/0x268) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859071] [<8013d9a8>] (kthreadd) from [<80108148>] (ret_from_fork+0x14/0x2c) <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859074] Mem-Info: <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] active_anon:111120 inactive_anon:111179 isolated_anon:0 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] active_file:280 inactive_file:315 isolated_file:0 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] unevictable:0 dirty:0 writeback:0 unstable:0 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] slab_reclaimable:1349 slab_unreclaimable:2619 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] mapped:277 shmem:157 pagetables:1080 bounce:0 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859086] free:6098 free_pcp:307 free_cma:1027 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859096] Node 0 active_anon:444480kB inactive_anon:444716kB active_file:1120kB inactive_file:1160kB unevictable:0kB isolated(anon):0kB isolated(file):128kB mapped:1108kB dirty:0kB writeback:0kB shmem:628kB writeback_tmp:0kB unstable:0kB pages_scanned:5717 all_unreclaimable? yes <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859108] Normal free:24392kB min:16384kB low:20480kB high:24576kB active_anon:444480kB inactive_anon:444716kB active_file:1120kB inactive_file:1260kB unevictable:0kB writepending:0kB present:970752kB managed:949580kB mlocked:0kB slab_reclaimable:5396kB slab_unreclaimable:10476kB kernel_stack:2296kB pagetables:4320kB bounce:0kB free_pcp:1228kB local_pcp:0kB free_cma:4108kB <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859116] Normal: 93*4kB (UMEHC) 97*8kB (UMEH) 57*16kB (UMEH) 43*32kB (UMEH) 17*64kB (UMH) 12*128kB (UMH) 4*256kB (UMH) 4*512kB (UM) 3*1024kB (UMH) 0*2048kB 3*4096kB (MC) = 24492kB <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859160] 792 pages in swap cache <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859164] Swap cache stats: add 53092, delete 52300, find 15591/17295 <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859165] Free swap = 0kB <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859167] Total swap = 102396kB <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859169] 242688 pages RAM <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859171] 0 pages HighMem/MovableOnly <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859173] 5293 pages reserved <4>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859175] 2048 pages cma reserved <3>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859365] Out of memory: Kill process 2268 (mono) score 895 or sacrifice child <3>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859746] Killed process 2268 (mono) total-vm:1174764kB, anon-rss:882580kB, file-rss:0kB, shmem-rss:4kB <28>1 2018-02-03T22:03:08-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Main process exited, code=killed, status=9/KILL <29>1 2018-02-03T22:03:08-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Unit entered failed state. <28>1 2018-02-03T22:03:08-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Failed with result 'signal'. <13>1 2018-02-03T22:03:11.717428-07:00 NodeLink Web - - - Web config server started (http://x.x.x.x:8090) <13>1 2018-02-03T22:03:11.717428-07:00 NodeLink ISY - - - ISY resolved to x.x.x.x <13>1 2018-02-03T22:03:13.212868-07:00 NodeLink ISY - - - ISY Node Server config detected (profile 1) <29>1 2018-02-03T22:03:13-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Main process exited, code=exited, status=50/n/a <29>1 2018-02-03T22:03:13-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Unit entered failed state. <28>1 2018-02-03T22:03:13-07:00 cairo systemd 1 - - systemd[1]: nodelink.service: Failed with result 'exit-code'. <13>1 2018-02-03T22:03:15.889360-07:00 NodeLink ISY - - - ISY resolved to x.x.x.x <13>1 2018-02-03T22:03:15.889372-07:00 NodeLink Web - - - Web config server started (http://x.x.x.x:8090) <13>1 2018-02-03T22:03:17.304188-07:00 NodeLink ISY - - - ISY Node Server config detected (profile 1) <13>1 2018-02-03T22:03:25.508727-07:00 NodeLink Alarm - - - Alarm: EVL User Login - Password Sent [hwalrm1] <13>1 2018-02-03T22:03:25.527320-07:00 NodeLink Alarm - - - Alarm: EVL User Login Successful [hwalrm1] <13>1 2018-02-03T22:03:25.530282-07:00 NodeLink Alarm - - - Alarm: Status Request Sent [hwalrm1] <11>1 2018-02-03T22:24:05.745340-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-03T22:44:24.794493-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T00:31:25.152167-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T02:29:36.447580-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T02:31:28.685726-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <13>1 2018-02-04T02:37:05.634459-07:00 NodeLink TCP - - - TCP: No poll response, attempting to reconnect to alarm [hwalrm1] <11>1 2018-02-04T02:38:13.612090-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T02:49:22.128269-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T03:00:57.331931-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <11>1 2018-02-04T03:11:58.153373-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) <13>1 2018-02-04T04:15:28.810506-07:00 NodeLink TCP - - - TCP: No poll response, attempting to reconnect to alarm [hwalrm1] <13>1 2018-02-04T04:20:09.269678-07:00 NodeLink TCP - - - TCP: Reconnecting To Server [hwalrm1] <13>1 2018-02-04T04:22:43.473360-07:00 NodeLink TCP - - - TCP: Reconnecting To Server [hwalrm1] <13>1 2018-02-04T04:25:38.105772-07:00 NodeLink TCP - - - TCP: Reconnecting To Server [hwalrm1] <11>1 2018-02-04T04:32:12.941740-07:00 NodeLink ISY - - - ISY Error: Error getting web response from the ISY (The request timed out) Looking at last night, it took about 6 hours to crash. <3>1 2018-02-03T22:03:08-07:00 cairo kernel - - - kernel: [46100.859746] Killed process 2268 (mono) total-vm:1174764kB, anon-rss:882580kB, file-rss:0kB, shmem-rss:4kB <3>1 2018-02-04T04:34:27-07:00 cairo kernel - - - kernel: [69580.242318] Killed process 3796 (mono) total-vm:1084136kB, anon-rss:880748kB, file-rss:0kB, shmem-rss:4kB Any suggestions would be appreciated. Everything was updated as of yesterday before these logs. Specs/Versions: pi@cairo:~ $ lsb_release -a No LSB modules are available. Distributor ID: Raspbian Description: Raspbian GNU/Linux 9.3 (stretch) Release: 9.3 Codename: stretch Raspberry Pi 3 Model B Quad-Core BROADCOM 64bit ARMv8 1.2 GHz 1 GB RAM (RPi3) pi@cairo:~ $ mono --versionMono JIT compiler version 5.8.0.108 (tarball Fri Jan 19 18:55:10 UTC 2018) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notifications: epoll Architecture: armel,vfp+hard Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen (concurrent by default) 2018-02-04 04:34:44 - ISY NodeLink Server v0.9.4 started 2018-02-04 04:34:44 - Mono version: 5.8.0.108 (tarball Fri Jan 19 18:55:10 UTC 2018) pi@cairo:~ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 30678404 2684936 26717556 10% / devtmpfs 470180 0 470180 0% /dev tmpfs 474788 4 474784 1% /dev/shm tmpfs 474788 12756 462032 3% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 474788 0 474788 0% /sys/fs/cgroup /dev/mmcblk0p1 64456 22208 42248 35% /boot tmpfs 94956 0 94956 0% /run/user/1000 pi@cairo:~ $ top top - 08:18:30 up 3:43, 1 user, load average: 0.00, 0.01, 0.00 Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.5 us, 0.4 sy, 0.0 ni, 99.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 949580 total, 34208 free, 881536 used, 33836 buff/cache KiB Swap: 102396 total, 78360 free, 24036 used. 25948 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 569 root 20 0 921016 854796 6076 S 2.0 90.0 5:50.72 mono 2353 pi 20 0 8104 3156 2668 R 1.0 0.3 0:00.18 top 40 root 20 0 0 0 0 S 0.7 0.0 0:00.56 kswapd0 1 root 20 0 27060 5404 4652 S 0.0 0.6 0:02.62 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:00.54 ksoftirqd/0 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:+ 7 root 20 0 0 0 0 S 0.0 0.0 0:03.22 rcu_sched 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root rt 0 0 0 0 S 0.0 0.0 0:00.05 migration/0 10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-dr+ 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 13 root rt 0 0 0 0 S 0.0 0.0 0:00.05 migration/1 14 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1 16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:+ 17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
BillB66 Posted February 8, 2018 Author Posted February 8, 2018 I rebuilt the pi from scratch with a new sd card. Only thing i carried over was the config.xml. Seeing the same behaviors. Random timeouts from isy and mono being recycled from being out of memory.
io_guy Posted February 8, 2018 Posted February 8, 2018 Kind of odd, plenty of people around here running the same setup. What devices do you have?
BillB66 Posted February 8, 2018 Author Posted February 8, 2018 Only device I am running is an Ademco Alarm via Evisalink4. I have been running the setup unchanged for quite a while and the behavior started to show up a month or two ago. It wasn't until I setup the remote syslog that I noticed mono being recycled. I am in the process of putting together a script to kill mono when it's memory usage gets high and restart Nodelink. Nodelink becomes unresponsive before the system recycles mono for OOM. This will at least keep the system stable. The issues seemed to start with the timeouts coming from ISY. Any chance the connection is left open leaking the memory? I have reviewed the programs running in ISY, and I don't see anything out of the ordinary as far as long running programs and the such. Not sure how to troubleshoot the timeouts on the ISY side. This is the pattern I see as far as the ISY timeouts. Nothing of interest in the ISY event viewer. 2018-02-08 11:58:57 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1/report/status/ST/-1/25) 2018-02-08 11:58:13 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV6/0/25) 2018-02-08 11:58:15 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV4/0/25) 2018-02-08 11:58:16 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1/report/status/ST/1/25) 2018-02-08 11:58:17 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1/report/status/ST/-1/25) 2018-02-08 11:58:18 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV2/0/25) 2018-02-08 11:58:19 - ISY Error: Error getting web response from the ISY (The request timed out) 2018-02-08 11:58:20 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV5/0/25) 2018-02-08 11:58:21 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV1/0/25) 2018-02-08 11:58:22 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/ST/0/25) 2018-02-08 11:58:59 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV5/0/25) 2018-02-08 11:59:00 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV4/0/25) 2018-02-08 11:59:01 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV1/0/25) 2018-02-08 11:59:02 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/ST/0/25) 2018-02-08 11:59:03 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV3/0/25) 2018-02-08 11:59:04 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV6/0/25) 2018-02-08 11:59:05 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV2/0/25) 2018-02-08 11:59:06 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1/report/status/ST/-1/25) 2018-02-08 11:59:07 - ISY: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/1/nodes/n001_hwalrm1_part1/report/status/GV5/0/25)
BillB66 Posted February 8, 2018 Author Posted February 8, 2018 Sanitized Config.xml <?xml version="1.0" encoding="UTF-8"?> <sections> <section name="web config"> <item key="port" value="8090" /> </section> <section name="isy admin"> <item key="login" value="xxxx" /> <item key="password" value="xxxxx" /> <item key="use ssl" value="True" /> <item key="loginrequired" value="True" /> <item key="address" value="isy994.xxxx.xxx" /> <item key="nodeprofilenumber" value="1" /> <item key="updatenodeconfigs" value="True" /> <item key="lastconfigupdate" value="0.9.5.0" /> </section> <section name="general options"> <item key="verbose isy log" value="False" /> <item key="auto update" value="True" /> <item key="log to file" value="False" /> <item key="webloglevel" value="6" /> <item key="isyloglevel" value="7" /> </section> <section name="hwalrm1"> <item key="address" value="xxx.xxx.xx.xx" /> <item key="verboselog" value="False" /> <item key="devpassword" value="xxxx" /> <item key="disarmpassword" value="xxxx" /> <item key="partitions" value="1" /> <item key="zones" value="15" /> <item key="loglevel" value="7" /> </section> <section name="advanced rest"> <item key="timeout" value="10" /> <item key="retry delay" value="60" /> </section> <section name="syslog server"> <item key="enabled" value="True" /> <item key="address" value="xxx.xxx.xx.xx" /> <item key="level" value="7" /> </section> <section name="saveddevices"> <item key="device0" value="" name="hwalrm1" nick="Ademco" type="12" /> </section> </sections>
io_guy Posted February 8, 2018 Posted February 8, 2018 Try disabling NodeLink ssl to the isy. You may be the first person actually using that, maybe it has issues.
BillB66 Posted February 9, 2018 Author Posted February 9, 2018 Looks like the SSL setting may be the issue. I updated it 12 hours ago and mono/NodeLink.exe is sitting stable at 75M of memory. Thanks for the suggestion. Some feedback on the install, consider whether you want folks to run NodeLink under root or not. I changed rc.local to launch under the user "pi" rather then root: http://automationshack.com/Files/Raspbian_Setup_V5.pdf sudo -u pi mono /home/pi/node/NodeLink.exe &
paulbates Posted February 9, 2018 Posted February 9, 2018 FWIW, I started using the SSL to the ISY in January, it did not change how my pi operated. Paul
BillB66 Posted February 10, 2018 Author Posted February 10, 2018 Day 2. Definitely solved. No more timeouts and memory has steady stayed under 75M. Thanks for the help. Let me know in the release notes if you resolve the issue so I can re-enable.
io_guy Posted February 10, 2018 Posted February 10, 2018 Appears to be a mono bug. I can repeat it on my Pi but it's fine on Windows. I wouldn't recommend using HTTPS to the ISY regardless, I only added it for someone using NodeLink remotely. The ISY doesn't have the horsepower to handle a pounding of HTTPS REST requests. I have about 200 nodes/calls sync with my ISY on startup. NodeLink will pound them synchronously as fast as the ISY will accept. In my testing here the ISY takes almost 10x-20x longer to process the secure requests. It takes a couple minutes for the startup sync to complete when using HTTPS.
larryllix Posted February 10, 2018 Posted February 10, 2018 Appears to be a mono bug. I can repeat it on my Pi but it's fine on Windows. I wouldn't recommend using HTTPS to the ISY regardless, I only added it for someone using NodeLink remotely. The ISY doesn't have the horsepower to handle a pounding of HTTPS REST requests. I have about 200 nodes/calls sync with my ISY on startup. NodeLink will pound them synchronously as fast as the ISY will accept. In my testing here the ISY takes almost 10x-20x longer to process the secure requests. It takes a couple minutes for the startup sync to complete when using HTTPS. I take that ISY dumps all or nothing and doesnt compartmentalise for the first data grab then?NodeLink gets the whole kit and kaboodle, need it or not? Sent from my SGH-I257M using Tapatalk
io_guy Posted February 10, 2018 Posted February 10, 2018 ISY REST calls are single discrete calls. That do not allow bulk data send.
paulbates Posted February 10, 2018 Posted February 10, 2018 Appears to be a mono bug. I can repeat it on my Pi but it's fine on Windows. I wouldn't recommend using HTTPS to the ISY regardless, I only added it for someone using NodeLink remotely. The ISY doesn't have the horsepower to handle a pounding of HTTPS REST requests. I have about 200 nodes/calls sync with my ISY on startup. NodeLink will pound them synchronously as fast as the ISY will accept. In my testing here the ISY takes almost 10x-20x longer to process the secure requests. It takes a couple minutes for the startup sync to complete when using HTTPS. It seems like point 2 in this link is related to the problem as hit by another codebase Does mono use open SSL? If yes, point 2 (first link) rings familiar. I just did an update/upgrade based on this post and openssl was part of it. Before the update, if I sat and stared at the admin console and a thermostat for a while, I can notice a delay sometimes.. but talking 10 seconds or so if and when it happens. Now that I did the update, it will be hard for me to tell if this openSSL update does anything (if in fact it applies) because I only get a handful of messages each week. I've just lived with it as its not really impactful functionality wise to me. However the first article also suggests mono SSL can't be counted on to support SSL securely (point 1 in first link). I personally don't have a way to prove/disprove that. Not asking for anything to be done here, just wondering if that is the problem, and if using SSL under mono is realistically helping me with security Paul
io_guy Posted February 10, 2018 Posted February 10, 2018 Last I saw it was using BoringSSL (since v4.8 or so), which is a Google OpenSSL fork. The speed is not just mono. I can see the speed difference in Windows as well. I wouldn't read to much into any of those articles. They're old and opinionated.
paulbates Posted February 10, 2018 Posted February 10, 2018 I wouldn't read to much into any of those articles. They're old and opinionated. Much like myself :D Thanks io_guy
io_guy Posted February 17, 2018 Posted February 17, 2018 Definitely a mono bug. I've changed about 500 lines of code and moved all http calls to the latest Framework API. This only happens in mono and with https. I can keep it from happening but there is a side affect that the http object gets flushed every time, meaning additional open sockets. Playing with it now to determine the lesser of the two evils.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.