Comment on the initial post... AFAIC all your /etc/sysctl/ settings look benign, But be aware that there is an effort to deprecate /etc/sysctl. Inspect the file on a newly installed system to view the alternative sysctl files which will likely not be deprecated. I can't believe this is happening (/etc/sysctl/) has been such a standard location to implement proc settings and more since forever. But, that's just tomorrow and isn't today... Your settings look fine to me.
Your post suggests you think that your problem might be network or disk related... You have to narrow that down because those are very different... Remember when you reallocate resources from system to network as you've done that you're stealing from the system to grant to networking. If your system needs resources, you'll have to re-optimize. To monitor and analyze your disk I/O, you should use the utility iotop. For the system, of course you can use top, htop or any of a variety of other possible utilities. If optimization is going to be an ongoing desire, you should consider instrumenting your system and set up network monitoring, there are many different guides on how to do this both FOSS and commercial, from Nagios and Nagios clones to commercial apps in combination with sensors. You should also consider whether you should be monitoring from within your Guest or on the HostOS. Don't know if you need a read on what you're doing to optimize, I wrote the article long ago based on an earlier openSUSE, everything in it and what you're currently doing should be just as effective on current openSUSE https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection HTH, Tony On Mon, Dec 23, 2019 at 10:59 AM Tony Su <[email protected]> wrote: > > I'm going to guess that you didn't install your Xen on your HostOS > using "the" recommended standard procedure... Which is to use the YaST > Virtualization module. If you did that, then you shouldn't have > variations. Also, you would be prompted to install a bridge device. > > That said, I don't know how old your HostOS installations are (except > for any you say you just installed). I am not involved with or track > what the Xen team does, but the Linux kernel has undergone several > related changes over the past 8 years or so... > There first was the "pre-ip" era when we used usermode utilities like > ipconfig regularly. > Then, the ip tools were introduced, I don't remember if they were > introduced initially as User mode tools are not. > Today we have version 2 of ip tools which are implemented as kernel > mode modules which comprise not only of the expanded ip commands which > more or less replace everything "pre-ip tools" but also bridging > devices and more. > In other words, practically everything networking that used to be > implemented as its own utility can now likely be done with an "ip" > command. > > That <might> explain the differences in your two installations but > shouldn't be a cause of problems... The "old way" should still be > supported, but as complex as the modifications to the Xen kernel > likely are, could be signposts to possible issues. Bottom line is that > I don't think you should have to get down into the weeds as you've > done and might be counter-productive, higher up methods should work > that accommodate whatever is happening at a lower level. > > Blabbering away... > Tony > > On Mon, Dec 23, 2019 at 1:26 AM Jan Beulich <[email protected]> wrote: > > > > On 21.12.2019 07:31, Glen wrote: > > > So just for laughs, I ran an lsmod in both modes, and sorted and diffed > > > them: > > > > > > The "clean" guest (which appears to be stable), has these four kernel > > > modules not present on the upgraded guest: > > > > > > iptable_raw > > > nf_conntrack_ftp > > > nf_nat_ftp > > > xt_CT > > > > > > The "dup'ped" guest (which seems to be crashable on a large local > > > rsync) has these modules not present on a clean install: > > > > > > auth_rpcgss > > > br_netfilter > > > bridge > > > > One of these two is, according to my experience, a fair candidate for > > your problems. I'm not a networking specialist at all, so I can't > > give any suggestions on how to convert the upgraded guest to a > > network config not requiring these modules. (Trying to get rid of > > br_netfilter alone may be easier, but again I'm not really > > knowledgeable in this area at all.) > > > > Jan > > > > > grace > > > intel_rapl > > > ipt_MASQUERADE > > > llc > > > lockd > > > nf_conntrack_netlink > > > nf_nat_masquerade_ipv4 > > > nfnetlink > > > nfs_acl > > > nfsd > > > overlay > > > sb_edac > > > stp > > > sunrpc > > > veth > > > xfrm_algo > > > xfrm_user > > > xt_addrtype > > > xt_nat > > > > > > Both guests share these additional sysctl.conf settings: > > > > > > kernel.panic = 5 > > > vm.panic_on_oom = 2 > > > vm.swappiness = 0 > > > net.ipv6.conf.all.autoconf = 0 > > > net.ipv6.conf.default.autoconf = 0 > > > net.ipv6.conf.eth0.autoconf = 0 > > > net.ipv4.tcp_fin_timeout = 10 > > > net.ipv4.tcp_tw_reuse = 0 > > > > > > The dup'ped guest has these additional sysctl.conf settings: > > > > > > net.ipv4.tcp_tw_recycle = 0 > > > net.core.netdev_max_backlog=300000 > > > net.core.somaxconn = 2048 > > > net.core.rmem_max=67108864 > > > net.core.wmem_max=67108864 > > > net.ipv4.ip_local_port_range=15000 65000 > > > net.ipv4.tcp_sack=0 > > > net.ipv4.tcp_rmem=4096 87380 67108864 > > > net.ipv4.tcp_wmem=4096 65536 67108864 > > > > > > all of which have, more or less, worked well in the past (when > > > everything was on 42.3) and may or may not be relevant here. > > > > > > I'm sorry, I feel like I'm missing something obvious here, but I can't > > > see it. I would be grateful for any guidance or insights into this. > > > Yes, in addition to trying to upgrade my client in place to 15.1, I > > > could just build a new guest by hand, but that would be even more > > > time-consuming and seems like it should not be necessary. If I might > > > quote from the kernel, "Dazed and confused, but trying to continue" is > > > exactly how I'm feeling here. Why could this guest be hanging? Why > > > does an NMI bring it back? What should I do next? Anything anyone > > > would be willing to point me to or suggest would be gratefully > > > appreciated. > > > > > > Glen > > > > > > > -- > > To unsubscribe, e-mail: [email protected] > > To contact the owner, e-mail: [email protected] > > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
