Search results

If you want performance as in IO the only way to go is using RAID 10 (striped mirrors). More stripes means higher performance. The explanation given here is very god: https://www.youtube.com/watch?v=GuUh3bkzaKE

My impression is also that linux bridge is the stable and simple choice but with fewer features than ovs. Whether linux bridge or ovs is simpler to configure is a matter of taste ;-) Looking forward to see the result of your test. A comparison of cpu usage order load could be interesting too?

Anybody here aware of performance comparison tests made lately between openvswitch and linux bridge?

Just choose other disks for system under installation. After installation you can create your data pool on your disks assigned for that purpose.

The most obvious reason to your bad performance is that you use ZFS against recommendation. A ZFS filesystem should always be made of hole disks and not partitions. I would add another disk for system and boot partition and then recreate the ZFS filesystem on the 4 hole disks.

Try changing netmtu to see whether this fixes your problem. Default for netmtu is 1500.

corosync-qdevice is on version 3.0.0-4 in Debian Buster for ARM, so a simple upgrade of your PI to Debian Buster as well as with your PVE nodes and the issues should be solved. PS. corosync-qdevice-3.0.0-4 is backwards compatible with the corosync-2.x so you can upgrade your PI to Buster before...

Proxmox 6 should be available soon. Debian Buster ships 6. July 2019: https://lists.debian.org/debian-devel-announce/2019/06/msg00003.html

Except if you specify command interpreter on the command line like: perl ./test bash some_bash_script

This is an Ubuntu bug only. Debian does not use LXD.

Another thing to take into consideration is storage efficiency. You should try to match volblock size with actual size of the written blocks. If you primarily do 4k writes, like most database systems, then favor a volblock size of 4k.

I have narrowed it down to a problem when I choose to have the syslog displayed and it is not specific to any browser. What happens is that pveproxy simply becomes unresponsible and a systemctl restart pveproxy.service is required to make the gui functional again.

You cannot compare 60.x to 66.x. They are to different. The same goes for comparing 52.x against 60.x.

Maybe you could explain the details of how it works on the wiki when you have it all working? Benchmarks are also welcome ;-)

Hi Wolfgang, Ditto here: dpkg -s firefox-esr Package: firefox-esr Status: install ok installed Priority: optional Section: web Installed-Size: 162542 Maintainer: Maintainers of Mozilla-related packages <team+pkg-mozilla@tracker.debian.org> Architecture: amd64 Version: 60.6.1esr-1

Try reading this: https://serverfault.com/questions/824932/why-zfs-file-system-is-not-shared-after-boot/824956

Hi all, Anybody else experiences problems with the webui and firefox-esr? If I have the webui running in a tab of firefox-esr for several hours the tab will crash and the only way to fix it is to close the tab. The same thing does not happen with the normal firefox.

Without performance numbers it is impossible to give you any advice.

After installation a proxmox node always defaults to use the pve-enterprise repository which, in case of a missing subscription, will always return an empty list and restrict to fetching packages from official Debian repositories. Always have this in mind or visit...

And match it with this one: dpkg -s corosync-qdevice Package: corosync-qdevice Status: install ok installed Priority: optional Section: admin Installed-Size: 504 Maintainer: Debian HA Maintainers <debian-ha-maintainers@lists.alioth.debian.org> Architecture: amd64 Source: corosync Version: 2.4.4-pve1