IPv6 chellange and OpenBSD

[Daniele B.]

Hello,

Between the updates of my web stuff I came also to notice the first ipv6 hits, 
how nicee
and immediately I found myself into the upgrade of the existing infrastructure 
to ipv6.
>From yesterday I'm offically up in ipv6 fashion with all my web apps.

I take this opportunity to ask two/three questions.
1) OpenBSD supports ipv6 from a while. Promiscuouse mode is a finished game or 
otherwise..?
2) We are all Tcp/Ip 4 Certified but anyway - much requested - iyho is "ipv6 
stack" all that safer that we can trust or regrettly...?
3) Can you advise about hosting providers in terms of managed VPS with OpenBSD, 
in North America and Europe?

Thanks!

-- Daniele Bonini

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Michael Hekeler]

> It is all about the dev environment: more precisely I
> need to be able to choose the moment when to switch to PHP[N] and do
> entering in the update process of all my web apps, thats it.

You can have multiple vm's with old versions.
E.g. you can keep an openbsd 60 vm with PHP 5.5.37.

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Michael Hekeler]

Am 15.02.23 10:41 schrieb Crystal Kolipe:
> On Wed, Feb 15, 2023 at 02:10:17PM +0100, Michael Hekeler wrote:
> > It is pointless to send to the list and in adddition to individuals.
> 
> If you don't want to receive individual replies to list mail, then consider
> setting the
> 
> Mail-Followup-To:
> 
> header in your mail client.

Thank you very much - I didn't know that before.

 
> Some subscribers to the lists _do_ prefer to be cc'ed on threads that they are
> involved in for various reasons, and although setting this header is not a
> guarantee that your preference will be respected, it increases the chances of
> it and also that other posters to that particular thread will be maintained in
> the CC list as per their preference.

Oh - I didn't know this too.
I always do  on a mailinglist so that the reply will go to
the list only. I always thought that some subscribers here cc'ed the
original sender accidentally. But if some subcribers prefer it to be
cc'ed then this makes sense now. Thanks for the clarification :)

Re: Simple PF Router/Firewall/NAT requirements: was Performance optimizing OpenBSD 7.2

[patric conant]

no

On Wed, Feb 15, 2023 at 10:21 PM Steve Litt 
wrote:

> Claudio Jeker said on Wed, 15 Feb 2023 14:14:11 +0100
>
>
> >I think the state-mismatch is a result of hitting the state limit and
> >not the other way around.  At over 90'000 states the default timeouts
> >are reduced by more than 50% and so states are removed too soon
> >resulting in a state-mismatch.
> >
> >So first bump the limit up and then look at the counters again.
>
> Within the next three months I'll be building a hardware (not VM)
> OpenBSD machine with pf filtering to Route, firewall and NAT between my
> house's IPV4 192.168.0.0/24 network and the Internet. My Internet is
> about 26Mbit down and 3.5Mbit up. Do you think I'll need to worry about
> state limits, states or state-mismatches?
>
> Thanks,
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
>
>

-- 
Patric Conant
Mirage Computing Lead Consultant
@MirageComputing on twitter
https://m.facebook.com/MirageComputing/
316 409 2424

Simple PF Router/Firewall/NAT requirements: was Performance optimizing OpenBSD 7.2

[Steve Litt]

Claudio Jeker said on Wed, 15 Feb 2023 14:14:11 +0100


>I think the state-mismatch is a result of hitting the state limit and
>not the other way around.  At over 90'000 states the default timeouts
>are reduced by more than 50% and so states are removed too soon
>resulting in a state-mismatch.
>
>So first bump the limit up and then look at the counters again.

Within the next three months I'll be building a hardware (not VM)
OpenBSD machine with pf filtering to Route, firewall and NAT between my
house's IPV4 192.168.0.0/24 network and the Internet. My Internet is
about 26Mbit down and 3.5Mbit up. Do you think I'll need to worry about
state limits, states or state-mismatches?

Thanks,

SteveT

Steve Litt 
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Steve Litt]

Daniele Bonini said on Wed, 15 Feb 2023 21:27:23 +0100


>I was trying different options like an OS, and my focus
>went on FreeBSD and OpenBSD. 

I've never been able to get FreeBSD or NetBSD or Dragonfly running.
OpenBSD was easy and very stable.

SteveT

Steve Litt 
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm

Ensuring data integrity

[iio7]

In the latest book by Michael Lucas, OpenBSD Mastery: Filesystems, Michael
writes, "A filesystem should put data on disk. That data should be safely
stored and reliably read. That's it. Error checking? Deduplication? No.
The operating system has other tools for ensuring data integrity and
compactness."

If I setup a couple of drives in a RAID mirror on OpenBSD to serve as
a NAS box, what is the best way to ensure data integrity?

-- 
 Sent with Tutanota, enjoy secure & ad-free emails. 

Re: 7.2: Console Errors

[Daniele Bonini]

Stuart Henderson  wrote:

> >
> > Can't find the pid in the system.. :D  
> 
> ps -kax

me# ps -kax | grep 80703
80703 ??  DK   0:27.08 (i915_flip)

Actually the Console contains:
drm:pid80703;intel_pipe_update_start *ERROR* [drm] *ERROR* Potential
atomic update failure on pipe A
drm:pid80703;intel_pipe_update_start *ERROR* [drm] *ERROR* Potential
atomic update failure on pipe B
drm:pid80703;intel_pipe_update_start *ERROR* [drm] *ERROR* Potential
atomic update failure on pipe A
drm:pid80703;intel_pipe_update_end *ERROR* [drm] *ERROR* Atomic update
failure on pipe A (start=3125193 end=3125194) time 2 us, min 763, max
767, scanline start 764, end 768
drm:pid80703;intel_pipe_update_start *ERROR* [drm] *ERROR* Potential
atomic update failure on pipe A


-- Daniele Bonini

Re: Performance optimizing OpenBSD 7.2

[patric conant]

>
>
>
> 7 vmx "phys" ifs
> 3 em "phys" ifs
>

Are these 7 ports to vswitches and 3 pci-passthroughed physical ports? I
have had good luck passing physical nics into OpenBSD vms (running line
rate, on 1Gb, and getting close to 2Gb on 2.5 realteks) but em emulated
nics never keep up with their vmx counterparts in my experience.


-- 
Patric Conant
Mirage Computing Lead Consultant
@MirageComputing on twitter
https://m.facebook.com/MirageComputing/
316 409 2424

Re: 7.2: Console Errors

[Stuart Henderson]

On 2023-02-15, Daniele Bonini  wrote:
>
> drm:pid80703;intel_pipe_update_start *ERROR* [drm] *ERROR* Potential
> atomic update failure on pipe A
>
> repeated..
>
> Can't find the pid in the system.. :D

ps -kax


-- 
Please keep replies on the mailing list.

Re: Performance optimizing OpenBSD 7.2

[Lars Bonnesen]

systat tells me

One box:
  89450
IPKTS
  19438
OPKTS

The other:
  68814
IPKTS
  87939
OPKTS

As the box are doing L2VPN, the NIC's for the vlans that are being
stretched are in promiscuous mode - thus all traffic on the networks are
hitting this box I have default block saying block drop
I guess this causes the box to care as little as possible about packages it
really shouldn't care about.



On Wed, Feb 15, 2023 at 5:52 PM Stuart Henderson 
wrote:

> On 2023-02-15, Lars Bonnesen  wrote:
> > lbo@PLOSLOL2VPN:/etc$ pfctl -s info
> > Status: Enabled for 0 days 00:06:49  Debug: err
> >
> > State Table  Total Rate
> >   current entries   149331
> >   half-open tcp   5333
> >   searches  4462647255 1098.0/s
> >   inserts 78143904   191060.9/s
> >   removals77994573   190695.8/s
> > Counters
> >   match  250452866   612354.2/s
> >   bad-offset 00.0/s
> >   fragment   10.0/s
> >   short  00.0/s
> >   normalize  10.0/s
> >   memory   524795412831.2/s
> >   bad-timestamp  00.0/s
> >   congestion  14693.6/s
> >   ip-option  30.0/s
> >   proto-cksum 30127.4/s
> >   state-mismatch 145502864   355752.7/s
> >   state-insert 3050.7/s
> >   state-limit00.0/s
> >   src-limit  00.0/s
> >   synproxy   00.0/s
> >   translate  00.0/s
> >   no-route   00.0/s
>
> oof, how many packets/sec is the machine doing? ("systat ifs", IPKT/OPKT
> columns)
>
> mismatches are still really high.
>
> does this machine see packets in both directions of the traffic
> that it's passing? no active/active setup where the traffic is getting
> split, or asymmetric routing where it only sees traffic in one
> direction?
>
>
>
>

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Daniele Bonini]

"Theo de Raadt"  wrote:

> We would be happy to give you a refund if you are not happy.

First time I used OpenBSD was the middle of 2012, in China.

I was trying different options like an OS, and my focus
went on FreeBSD and OpenBSD. 

Despite the obvious notoriety of some OpenBSD software already at that
time, FreeBSD simply didn't and doesn't grant its users all what
OpenBSD does ( I know, you can say me that maybe tweaked is another story..). 

As OpenBSD was with me at the Shanghai Digital Plaza market to let 
me choose the new laptop.. today, it doesn't let me choose PHP version
yet - that's the pity - and doesn't support Unicode (Ie: the Chinese
lang) at system level - that's the pain, I must work with that!

As I can quietly say that OpenBSD continues to do a lot to save my batt:
since 2012, I developed tons of web apps with almost 85-90 managed
domains I own + the 3rd party ones.. No refund request. And in the end
if ChapGPT will be ever able to produce these kind of nice messages, 
I could, eventually, think to endorse it.. :D


-- Daniele Bonini
‎‎

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Umgeher Torgersen]

On Wed, Feb 15, 2023 at 11:03:37AM -0700, Theo de Raadt wrote:
> We would be happy to give you a refund if you are not happy.

OMG! hehehe

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Theo de Raadt]

We would be happy to give you a refund if you are not happy.


Daniele Bonini  wrote:

> 
> 
> Stuart Henderson  wrote:
> 
> > You're probably looking at the wrong OS then.
> 
> OpenBSD takes in my game *portability* at any level:
> I do backups of my system in 12min.. and I can put it almost on
> any hardware.. this not little thing.
> 
> It is defintely a problems of dev environment.
> 
> It is starting from the thought that other OS have Docker, etc,
> where I can *download* any php version on the fly.. so yes, the choice
> of OpenBSD can be judge wrong.
> 
> But for the posterity: I manage to work with Docker also online
> and with many other virtualization facilities so like I said before I
> can rationally choose to move things on live servers taking my
> portability God to the n extension.. But do not unplug me 
> like my daughter does pushing a plug button..
> 
> > (In any event, whatever OS you use, if you find it unacceptable
> > to have your systems broken after an upgrade, you really should test
> > those upgrades on a spare machine/VM first..)
> 
> As said above, there a no rumors of a broken OS around, like OpenBSD.
> And I work with the same hardware since decades.. 
> 
> It is all about the dev environment: more precisely I
> need to be able to choose the moment when to switch to PHP[N] and do
> entering in the update process of all my web apps, thats it.
> 
> However your suggestion is really a good one for everyone.
> 
> Thanks!
> 
> -- Daniele Bonini
> 

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Daniele Bonini]

Stuart Henderson  wrote:

> You're probably looking at the wrong OS then.

OpenBSD takes in my game *portability* at any level:
I do backups of my system in 12min.. and I can put it almost on
any hardware.. this not little thing.

It is defintely a problems of dev environment.

It is starting from the thought that other OS have Docker, etc,
where I can *download* any php version on the fly.. so yes, the choice
of OpenBSD can be judge wrong.

But for the posterity: I manage to work with Docker also online
and with many other virtualization facilities so like I said before I
can rationally choose to move things on live servers taking my
portability God to the n extension.. But do not unplug me 
like my daughter does pushing a plug button..

> (In any event, whatever OS you use, if you find it unacceptable
> to have your systems broken after an upgrade, you really should test
> those upgrades on a spare machine/VM first..)

As said above, there a no rumors of a broken OS around, like OpenBSD.
And I work with the same hardware since decades.. 

It is all about the dev environment: more precisely I
need to be able to choose the moment when to switch to PHP[N] and do
entering in the update process of all my web apps, thats it.

However your suggestion is really a good one for everyone.

Thanks!

-- Daniele Bonini

Re: Performance optimizing OpenBSD 7.2

[Stuart Henderson]

On 2023-02-15, Lars Bonnesen  wrote:
> lbo@PLOSLOL2VPN:/etc$ pfctl -s info
> Status: Enabled for 0 days 00:06:49  Debug: err
>
> State Table  Total Rate
>   current entries   149331
>   half-open tcp   5333
>   searches  4462647255 1098.0/s
>   inserts 78143904   191060.9/s
>   removals77994573   190695.8/s
> Counters
>   match  250452866   612354.2/s
>   bad-offset 00.0/s
>   fragment   10.0/s
>   short  00.0/s
>   normalize  10.0/s
>   memory   524795412831.2/s
>   bad-timestamp  00.0/s
>   congestion  14693.6/s
>   ip-option  30.0/s
>   proto-cksum 30127.4/s
>   state-mismatch 145502864   355752.7/s
>   state-insert 3050.7/s
>   state-limit00.0/s
>   src-limit  00.0/s
>   synproxy   00.0/s
>   translate  00.0/s
>   no-route   00.0/s

oof, how many packets/sec is the machine doing? ("systat ifs", IPKT/OPKT 
columns)

mismatches are still really high.

does this machine see packets in both directions of the traffic
that it's passing? no active/active setup where the traffic is getting
split, or asymmetric routing where it only sees traffic in one
direction?

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Stuart Henderson]

On 2023-02-15, Daniele Bonini  wrote:
>
> Let's say like OpenBSD like a PHP dev environment doesn't come 
> in handy at time. Try to think if for any reason sysupgrade upgrade
> my php system version, they days after I will have no launch for a
> while. It is not acceptable..

You're probably looking at the wrong OS then.

Old binaries are not particularly expected to work long term
and may break from release to release, so even if you're using self-
built older PHP versions you'll have some extra work to do to rebuild
them on a newer OS version after some upgrades (and as time goes
by, you may have extra work to add patches to PHP to get it to build
from source, either due to changes in the OS or in dependencies).

(In any event, whatever OS you use, if you find it unacceptable
to have your systems broken after an upgrade, you really should test
those upgrades on a spare machine/VM first..)


-- 
Please keep replies on the mailing list.

Re: Performance optimizing OpenBSD 7.2

[Lars Bonnesen]

I think that I am now hitting a bottleneck somewhere else.

Thanks for the help so far... I might come back thirsty for more later...
(-:

Regards, Lars.

On Wed, Feb 15, 2023 at 4:13 PM Lars Bonnesen 
wrote:

> lbo@PLOSLOL2VPN:/etc$ pfctl -s info
> Status: Enabled for 0 days 00:06:49  Debug: err
>
> State Table  Total Rate
>   current entries   149331
>   half-open tcp   5333
>   searches  4462647255 1098.0/s
>   inserts 78143904   191060.9/s
>   removals77994573   190695.8/s
> Counters
>   match  250452866   612354.2/s
>   bad-offset 00.0/s
>   fragment   10.0/s
>   short  00.0/s
>   normalize  10.0/s
>   memory   524795412831.2/s
>   bad-timestamp  00.0/s
>   congestion  14693.6/s
>   ip-option  30.0/s
>   proto-cksum 30127.4/s
>   state-mismatch 145502864   355752.7/s
>   state-insert 3050.7/s
>   state-limit00.0/s
>   src-limit  00.0/s
>   synproxy   00.0/s
>   translate  00.0/s
>   no-route   00.0/s
>
> On Wed, Feb 15, 2023 at 2:15 PM Claudio Jeker 
> wrote:
>
>> On Wed, Feb 15, 2023 at 01:01:10PM -, Stuart Henderson wrote:
>> > On 2023-02-15, Lars Bonnesen  wrote:
>> > > One says:
>> > >
>> > > # pfctl -s info
>> > > Status: Enabled for 0 days 10:56:43  Debug: err
>> > >
>> > > State Table  Total Rate
>> > >   current entries91680
>> >
>> > Lots of entries, close to the default:
>> >
>> > $ doas pfctl -sm
>> > stateshard limit   10
>> > src-nodes hard limit1
>> > frags hard limit65536
>> > tableshard limit 1000
>> > table-entries hard limit   20
>> > pktdelay-pkts hard limit1
>> > anchors   hard limit  512
>> >
>> > >   half-open tcp   4032
>> > >   searches  313230429479494.1/s
>> > >   inserts 60916552 1546.0/s
>> > >   removals60824872 1543.7/s
>> > > Counters
>> > >   match   79164265 2009.1/s
>> > >   bad-offset 00.0/s
>> > >   fragment   10.0/s
>> > >   short  00.0/s
>> > >   normalize  00.0/s
>> > >   memory   1768012   44.9/s
>> >
>> > And this most likely means that you've been bumping into the
>> > state limit plenty of times already.
>> >
>> > >   bad-timestamp  00.0/s
>> > >   congestion  12010.0/s
>> > >   ip-option  00.0/s
>> > >   proto-cksum  3870.0/s
>> > >   state-mismatch  82794949 2101.2/s
>> >
>> > Loads of state mismatches and, looking at the rate, this is
>> > probably on an ongoing basis.
>> >
>> > Check to make sure that all packets match either a "pass" or "block"
>> > rule (the easiest way to do this is usually to have a simple "block"
>> > or "block log" as the first rule) - if you don't have any matching
>> > rule in the config, there is an implicit default which passes traffic
>> > *without* creating state.
>> >
>> > (One particularly common result of this is that TCP window scaling
>> > isn't handled properly such that longer lived or fast TCP connections
>> > are likely to slow down or stall.)
>> >
>> > You might also need to bump the state limit, but I'd check the above
>> > first because the high number of states might be caused because of
>> > mismatches.
>>
>> I think the state-mismatch is a result of hitting the state limit and not
>> the other way around.  At over 90'000 states the default timeouts are
>> reduced by more than 50% and so states are removed too soon resulting in a
>> state-mismatch.
>>
>> So first bump the limit up and then look at the counters again.
>>
>> --
>> :wq Claudio
>>
>>

Re: Performance optimizing OpenBSD 7.2

[Lars Bonnesen]

lbo@PLOSLOL2VPN:/etc$ pfctl -s info
Status: Enabled for 0 days 00:06:49  Debug: err

State Table  Total Rate
  current entries   149331
  half-open tcp   5333
  searches  4462647255 1098.0/s
  inserts 78143904   191060.9/s
  removals77994573   190695.8/s
Counters
  match  250452866   612354.2/s
  bad-offset 00.0/s
  fragment   10.0/s
  short  00.0/s
  normalize  10.0/s
  memory   524795412831.2/s
  bad-timestamp  00.0/s
  congestion  14693.6/s
  ip-option  30.0/s
  proto-cksum 30127.4/s
  state-mismatch 145502864   355752.7/s
  state-insert 3050.7/s
  state-limit00.0/s
  src-limit  00.0/s
  synproxy   00.0/s
  translate  00.0/s
  no-route   00.0/s

On Wed, Feb 15, 2023 at 2:15 PM Claudio Jeker 
wrote:

> On Wed, Feb 15, 2023 at 01:01:10PM -, Stuart Henderson wrote:
> > On 2023-02-15, Lars Bonnesen  wrote:
> > > One says:
> > >
> > > # pfctl -s info
> > > Status: Enabled for 0 days 10:56:43  Debug: err
> > >
> > > State Table  Total Rate
> > >   current entries91680
> >
> > Lots of entries, close to the default:
> >
> > $ doas pfctl -sm
> > stateshard limit   10
> > src-nodes hard limit1
> > frags hard limit65536
> > tableshard limit 1000
> > table-entries hard limit   20
> > pktdelay-pkts hard limit1
> > anchors   hard limit  512
> >
> > >   half-open tcp   4032
> > >   searches  313230429479494.1/s
> > >   inserts 60916552 1546.0/s
> > >   removals60824872 1543.7/s
> > > Counters
> > >   match   79164265 2009.1/s
> > >   bad-offset 00.0/s
> > >   fragment   10.0/s
> > >   short  00.0/s
> > >   normalize  00.0/s
> > >   memory   1768012   44.9/s
> >
> > And this most likely means that you've been bumping into the
> > state limit plenty of times already.
> >
> > >   bad-timestamp  00.0/s
> > >   congestion  12010.0/s
> > >   ip-option  00.0/s
> > >   proto-cksum  3870.0/s
> > >   state-mismatch  82794949 2101.2/s
> >
> > Loads of state mismatches and, looking at the rate, this is
> > probably on an ongoing basis.
> >
> > Check to make sure that all packets match either a "pass" or "block"
> > rule (the easiest way to do this is usually to have a simple "block"
> > or "block log" as the first rule) - if you don't have any matching
> > rule in the config, there is an implicit default which passes traffic
> > *without* creating state.
> >
> > (One particularly common result of this is that TCP window scaling
> > isn't handled properly such that longer lived or fast TCP connections
> > are likely to slow down or stall.)
> >
> > You might also need to bump the state limit, but I'd check the above
> > first because the high number of states might be caused because of
> > mismatches.
>
> I think the state-mismatch is a result of hitting the state limit and not
> the other way around.  At over 90'000 states the default timeouts are
> reduced by more than 50% and so states are removed too soon resulting in a
> state-mismatch.
>
> So first bump the limit up and then look at the counters again.
>
> --
> :wq Claudio
>
>

Re: Q: Error: mount_mfs: mmap: Cannot allocate memory

[Crystal Kolipe]

On Wed, Feb 15, 2023 at 03:10:08PM +0100, Why 42? The lists account. wrote:
> However, I also tried testing the same two filesystems using the
> "Flexible IO Tester" or fio (it's available as a package). When I used it
> to do random 4K reads and writes, I appear to have the opposite result:

...

> I wonder why that would be?

For a start, I would test using something other than /dev/zero as the data
source.

It's entirely possible that the firmware on an SSD would special case writing
a block that contains only 0x00 bytes.

In that case, and assuming that the filesystem block boundaries align with
the SSD's own internal flash block layout, the SSD would only need to update
it's metadata to point those LBA blocks to an internal 'zero' block.

This would virtually eliminate the overhead of actually writing to the flash,
and allow it to accept data from the host at a much faster speed.

As soon as you write a single non-0x00 byte, the drive would have to do a
propper write to the main flash memory and not just the area which contains
it's internal LBA to flash block mapping, (which may also be write-cached).

Depending on the state of the SSD, (recently secerased, used with another
OS which supports TRIM, alignment of the filesystem blocks with the raw
flash blocks, etc, etc), this could mean either a write, or a
read-erase-write cycle.

Using /dev/zero as the source definitely makes it a synthetic benchmark.

Re: Q: Error: mount_mfs: mmap: Cannot allocate memory

[Why 42? The lists account.]

On Mon, Feb 13, 2023 at 01:50:13PM -, Stuart Henderson wrote:
> ...
> It maybe worth checking whether mfs is actually helping -
> it's easy to assume that because it's in RAM it must be fast,
> but I've had machines where mfs was slower than SSD
> (https://marc.info/?l=openbsd-misc=164942119618029=2),
> also it's taking memory that could otherwise be used by
> buffer cache.

Hi All,

Since you mentioned it, I thought I would retry your dd test ...

# mount | grep /tmp
mfs:15266 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=16777216 
512-blocks)

% cd !$ ; for i in `jot 5`; do dd if=/dev/zero of=mfs bs=1m count=990 2>&1 | 
grep bytes; done
cd /tmp/dd_test ; for i in `jot 5`; do dd if=/dev/zero of=mfs bs=1m count=990 
2>&1 | grep bytes; done
1038090240 bytes transferred in 1.376 secs (754215208 bytes/sec)
1038090240 bytes transferred in 1.189 secs (872536649 bytes/sec)
1038090240 bytes transferred in 1.227 secs (845718432 bytes/sec)
1038090240 bytes transferred in 1.186 secs (874866632 bytes/sec)
1038090240 bytes transferred in 1.254 secs (827186370 bytes/sec)

# mount | grep /fast
/dev/sd1l on /fast type ffs (local, nodev, nosuid, softdep)
# dmesg | grep sd1
sd1 at scsibus2 targ 1 lun 0: 
...

% cd /fast/dd_test ; for i in `jot 5`; do dd if=/dev/zero of=fast bs=1m 
count=990 2>&1 | grep bytes; done 
1038090240 bytes transferred in 0.871 secs (1191076597 bytes/sec)
1038090240 bytes transferred in 0.635 secs (1633246669 bytes/sec)
1038090240 bytes transferred in 0.615 secs (1685529408 bytes/sec)
1038090240 bytes transferred in 0.605 secs (1714639562 bytes/sec)
1038090240 bytes transferred in 0.612 secs (1694489764 bytes/sec)


So it seems that the Samsung NVMe device is much faster ...

However, I also tried testing the same two filesystems using the
"Flexible IO Tester" or fio (it's available as a package). When I used it
to do random 4K reads and writes, I appear to have the opposite result:

fio --name=rand_mmap_r+w --directory=/tmp/fio_test --rw=randrw --blocksize=4k 
--size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 --thread 
--numjobs=1 --group_reporting
...
Run status group 0 (all jobs):
   READ: bw=130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io=30.0GiB 
(32.2GB), run=236394-236394msec
  WRITE: bw=130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io=30.0GiB 
(32.2GB), run=236394-236394msec

% fio --name=rand_mmap_r+w --directory=/fast/fio_test --rw=randrw 
--blocksize=4k --size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 
--thread --numjobs=1 --group_reporting
...
Run status group 0 (all jobs):
   READ: bw=34.8MiB/s (36.5MB/s), 34.8MiB/s-34.8MiB/s (36.5MB/s-36.5MB/s), 
io=20.4GiB (21.9GB), run=60-60msec
  WRITE: bw=34.8MiB/s (36.4MB/s), 34.8MiB/s-34.8MiB/s (36.4MB/s-36.4MB/s), 
io=20.4GiB (21.9GB), run=60-60msec

I wonder why that would be?

Disclaimer: I know almost nothing about fio, I've never used it before.
In particular, it isn't clear to me what the correct/best choice is for
the "ioengine" option. (I played around with a few different settings,
that's why you can see that "mmap" in the (test)name argument.)

This is on a 8th generation i5 Intel NUC running a recent snapshot: 7.2
GENERIC.MP#1049

The CPU has 4 cores, hyperthreading is off. The underlying device for
"/fast" is a Samsung M.2 NVMe "stick":
nvme0: Samsung SSD 970 EVO Plus 500GB, firmware 1B2QEXM7 ...

The full output from fio is included below for anyone who might be
interested ...

Cheers,
Robb.


fio --name=rand_mmap_r+w --directory=/tmp/fio_test --rw=randrw --blocksize=4k 
--size=6g --io_size=60g --runtime=600 --ioengine=psync --fsync=1 --thread 
--numjobs=1 --group_reporting
rand_mmap_r+w: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 
4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
Starting 1 thread
rand_mmap_r+w: Laying out IO file (1 file / 6144MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=134MiB/s,w=134MiB/s][r=34.3k,w=34.2k IOPS][eta 
00m:00s]
rand_mmap_r+w: (groupid=0, jobs=1): err= 0: pid=669956672: Wed Feb 15 13:52:03 
2023
  read: IOPS=33.3k, BW=130MiB/s (136MB/s)(30.0GiB/236394msec)
clat (nsec): min=1523, max=1504.6k, avg=5387.11, stdev=1201.82
 lat (nsec): min=1580, max=1504.7k, avg=5450.15, stdev=1203.46
clat percentiles (nsec):
 |  1.00th=[ 3632],  5.00th=[ 4576], 10.00th=[ 4832], 20.00th=[ 5024],
 | 30.00th=[ 5152], 40.00th=[ 5280], 50.00th=[ 5344], 60.00th=[ 5472],
 | 70.00th=[ 5600], 80.00th=[ 5792], 90.00th=[ 5984], 95.00th=[ 6176],
 | 99.00th=[ 6496], 99.50th=[ 6688], 99.90th=[13376], 99.95th=[18048],
 | 99.99th=[26240]
   bw (  KiB/s): min=126573, max=144312, per=100.00%, avg=133298.71, 
stdev=2476.36, samples=472
   iops: min=31643, max=36078, avg=33324.48, stdev=619.06, samples=472
  write: IOPS=33.2k, BW=130MiB/s (136MB/s)(30.0GiB/236394msec); 0 zone resets
clat (usec): min=3, max=1549, avg=13.84, stdev= 2.06
 lat (usec): min=3, max=1549, avg=13.92, stdev= 2.07
clat 

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Crystal Kolipe]

On Wed, Feb 15, 2023 at 02:10:17PM +0100, Michael Hekeler wrote:
> It is pointless to send to the list and in adddition to individuals.

If you don't want to receive individual replies to list mail, then consider
setting the

Mail-Followup-To:

header in your mail client.

Some subscribers to the lists _do_ prefer to be cc'ed on threads that they are
involved in for various reasons, and although setting this header is not a
guarantee that your preference will be respected, it increases the chances of
it and also that other posters to that particular thread will be maintained in
the CC list as per their preference.

And once again, a general reminder to everybody to _please_ respect the
established etiquette of -misc, keep posts on-topic, and not forward private
mail to the list without good reason.

Re: Performance optimizing OpenBSD 7.2

[Claudio Jeker]

On Wed, Feb 15, 2023 at 01:01:10PM -, Stuart Henderson wrote:
> On 2023-02-15, Lars Bonnesen  wrote:
> > One says:
> >
> > # pfctl -s info
> > Status: Enabled for 0 days 10:56:43  Debug: err
> >
> > State Table  Total Rate
> >   current entries91680
> 
> Lots of entries, close to the default:
> 
> $ doas pfctl -sm 
> stateshard limit   10
> src-nodes hard limit1
> frags hard limit65536
> tableshard limit 1000
> table-entries hard limit   20
> pktdelay-pkts hard limit1
> anchors   hard limit  512
> 
> >   half-open tcp   4032
> >   searches  313230429479494.1/s
> >   inserts 60916552 1546.0/s
> >   removals60824872 1543.7/s
> > Counters
> >   match   79164265 2009.1/s
> >   bad-offset 00.0/s
> >   fragment   10.0/s
> >   short  00.0/s
> >   normalize  00.0/s
> >   memory   1768012   44.9/s
> 
> And this most likely means that you've been bumping into the
> state limit plenty of times already.
> 
> >   bad-timestamp  00.0/s
> >   congestion  12010.0/s
> >   ip-option  00.0/s
> >   proto-cksum  3870.0/s
> >   state-mismatch  82794949 2101.2/s
> 
> Loads of state mismatches and, looking at the rate, this is
> probably on an ongoing basis.
> 
> Check to make sure that all packets match either a "pass" or "block"
> rule (the easiest way to do this is usually to have a simple "block"
> or "block log" as the first rule) - if you don't have any matching
> rule in the config, there is an implicit default which passes traffic
> *without* creating state.
> 
> (One particularly common result of this is that TCP window scaling
> isn't handled properly such that longer lived or fast TCP connections
> are likely to slow down or stall.)
> 
> You might also need to bump the state limit, but I'd check the above
> first because the high number of states might be caused because of
> mismatches.

I think the state-mismatch is a result of hitting the state limit and not
the other way around.  At over 90'000 states the default timeouts are
reduced by more than 50% and so states are removed too soon resulting in a
state-mismatch.

So first bump the limit up and then look at the counters again.

-- 
:wq Claudio

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Michael Hekeler]

Am 15.02.23 10:12 schrieb Daniele Bonini:
> 
> Michael Hekeler  wrote:
> 
> > You can run any PHP version you like.
> > You can run more than just single version.
> 
> ls http://ftp.openbsd.org/pub/OpenBSD/7.2/packages/amd64/ | grep
> 
> php-7.4.30p0.tgz   8197515 
> php-8.0.23p0.tgz   8771969 
> php-8.1.10p0.tgz   9017614
> 
> 
> Ok, let's support OpenBSD project by compile whatever PHP version,
> right? It's not that easy (c lib and diff dependencies), but it is
> nice..
> 
> I was waiting for an honest answer against my problematic dev and
> testing environment..

Actually this WAS a honest answer for your dev environment.

Anyway... please learn how to use mailinglists.
It is pointless to send to the list and in adddition to individuals.

Re: Performance optimizing OpenBSD 7.2

[Gábor LENCSE]

As for performance optimization, I think the direction is good, and perhaps
you could go even further if you have a load balancing device that can
distribute the traffic among the multiple VMs.

Not sure why reducing the memory should help. Also reducing the number of
virtual CPUs has probably little effect as well. The main point in reducing
the number of cores and disabling threads is to give modern CPUs more
thermal/power headroom to run the fewer CPUs at a higher clockspeed.
I doubt you get the same effect on vCPUs.
What helps is not the reducing of the resources, but reducing of the 
load. :-)


Please consider the following two cases:
- Full load to 1 "powerful" VM with 8 vCPUs and 8GB RAM
- 25% of the load to 1 "moderate" 1VM with 2 vCPUs and 2GB RAM

As OpenBSD does not benefit much from the 8 cores, the performance of 
the "powerful" VM and the "moderate" VMs is quite similar. But the load 
for each "moderate" VMs is only 25%.


Of course, my comparison is not completely fair, as the load balancing 
device also needs resources. But it can use e.g. Linux and FD.io VPP 
that has incredible performance due to using DPDK. So if you use one 
"moderate" VM for that purpose, its performance would be more than 
enough, whereas each of the other three "moderate" VMs will get about 
33-34% of the full load.


Best regards,

Gábor

Re: Performance optimizing OpenBSD 7.2

[Claudio Jeker]

On Wed, Feb 15, 2023 at 01:39:54PM +0100, Lars Bonnesen wrote:
> One says:
> 
> # pfctl -s info
> Status: Enabled for 0 days 10:56:43  Debug: err
> 
> State Table  Total Rate
>   current entries91680
>   half-open tcp   4032
>   searches  313230429479494.1/s
>   inserts 60916552 1546.0/s
>   removals60824872 1543.7/s
> Counters
>   match   79164265 2009.1/s
>   bad-offset 00.0/s
>   fragment   10.0/s
>   short  00.0/s
>   normalize  00.0/s
>   memory   1768012   44.9/s
>   bad-timestamp  00.0/s
>   congestion  12010.0/s
>   ip-option  00.0/s
>   proto-cksum  3870.0/s
>   state-mismatch  82794949 2101.2/s
>   state-insert 2300.0/s
>   state-limit00.0/s
>   src-limit  00.0/s
>   synproxy   00.0/s
>   translate  00.0/s
>   no-route   00.0/s
> 
> The other says:
> 
> # pfctl -s info
> Status: Enabled for 0 days 10:39:38  Debug: err
> 
> State Table  Total Rate
>   current entries93847
>   half-open tcp   8441
>   searches  3900545422   101634.9/s
>   inserts 69463584 1810.0/s
>   removals69369737 1807.5/s
> Counters
>   match  75220369719599.9/s
>   bad-offset 00.0/s
>   fragment   00.0/s
>   short  00.0/s
>   normalize  20.0/s
>   memory2124545.5/s
>   bad-timestamp  00.0/s
>   congestion 00.0/s
>   ip-option  00.0/s
>   proto-cksum00.0/s
>   state-mismatch  33380332  869.8/s
>   state-insert   00.0/s
>   state-limit00.0/s
>   src-limit  00.0/s
>   synproxy   00.0/s
>   translate  00.0/s
>   no-route   00.0/s
> 
> What does that tell us?

That you need to increase the state limit in pf.
pfctl -s info should not report any memory error.
pfctl -sm will show you the current limits. pf.conf(5) has info on how to
increase the limit (set limit).

-- 
:wq Claudio

Re: Performance optimizing OpenBSD 7.2

[Stuart Henderson]

On 2023-02-15, Lars Bonnesen  wrote:
> One says:
>
> # pfctl -s info
> Status: Enabled for 0 days 10:56:43  Debug: err
>
> State Table  Total Rate
>   current entries91680

Lots of entries, close to the default:

$ doas pfctl -sm 
stateshard limit   10
src-nodes hard limit1
frags hard limit65536
tableshard limit 1000
table-entries hard limit   20
pktdelay-pkts hard limit1
anchors   hard limit  512

>   half-open tcp   4032
>   searches  313230429479494.1/s
>   inserts 60916552 1546.0/s
>   removals60824872 1543.7/s
> Counters
>   match   79164265 2009.1/s
>   bad-offset 00.0/s
>   fragment   10.0/s
>   short  00.0/s
>   normalize  00.0/s
>   memory   1768012   44.9/s

And this most likely means that you've been bumping into the
state limit plenty of times already.

>   bad-timestamp  00.0/s
>   congestion  12010.0/s
>   ip-option  00.0/s
>   proto-cksum  3870.0/s
>   state-mismatch  82794949 2101.2/s

Loads of state mismatches and, looking at the rate, this is
probably on an ongoing basis.

Check to make sure that all packets match either a "pass" or "block"
rule (the easiest way to do this is usually to have a simple "block"
or "block log" as the first rule) - if you don't have any matching
rule in the config, there is an implicit default which passes traffic
*without* creating state.

(One particularly common result of this is that TCP window scaling
isn't handled properly such that longer lived or fast TCP connections
are likely to slow down or stall.)

You might also need to bump the state limit, but I'd check the above
first because the high number of states might be caused because of
mismatches.



-- 
Please keep replies on the mailing list.

Re: Performance optimizing OpenBSD 7.2

[Nick Holland]

On 2/15/23 04:54, Claudio Jeker wrote:

On Wed, Feb 15, 2023 at 10:28:57AM +0100, Gábor LENCSE wrote:

Hi Lars,

> I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
> now seems to hold the packages decently.

As for performance optimization, I think the direction is good, and perhaps
you could go even further if you have a load balancing device that can
distribute the traffic among the multiple VMs.


Not sure why reducing the memory should help. Also reducing the number of
virtual CPUs has probably little effect as well. The main point in reducing
the number of cores and disabling threads is to give modern CPUs more
thermal/power headroom to run the fewer CPUs at a higher clockspeed.
I doubt you get the same effect on vCPUs.


Quite some time ago, the story with VMware (and I'm guessing it is true of
all x86 virtualization) is that to have "time" on the processor, ALL the
required CPUs had to be available.  A single CPU VM could almost always
find time to run...an 8 CPU VM had to wait until there were all eight
cores available to run, so if your task didn't use lots of cores, you
often lost by requesting more than you needed.  Not sure how true it was
"back then" or now, but if better performance is seen with fewer cores,
this might be why.

Nick.

Re: Performance optimizing OpenBSD 7.2

[Lars Bonnesen]

One says:

# pfctl -s info
Status: Enabled for 0 days 10:56:43  Debug: err

State Table  Total Rate
  current entries91680
  half-open tcp   4032
  searches  313230429479494.1/s
  inserts 60916552 1546.0/s
  removals60824872 1543.7/s
Counters
  match   79164265 2009.1/s
  bad-offset 00.0/s
  fragment   10.0/s
  short  00.0/s
  normalize  00.0/s
  memory   1768012   44.9/s
  bad-timestamp  00.0/s
  congestion  12010.0/s
  ip-option  00.0/s
  proto-cksum  3870.0/s
  state-mismatch  82794949 2101.2/s
  state-insert 2300.0/s
  state-limit00.0/s
  src-limit  00.0/s
  synproxy   00.0/s
  translate  00.0/s
  no-route   00.0/s

The other says:

# pfctl -s info
Status: Enabled for 0 days 10:39:38  Debug: err

State Table  Total Rate
  current entries93847
  half-open tcp   8441
  searches  3900545422   101634.9/s
  inserts 69463584 1810.0/s
  removals69369737 1807.5/s
Counters
  match  75220369719599.9/s
  bad-offset 00.0/s
  fragment   00.0/s
  short  00.0/s
  normalize  20.0/s
  memory2124545.5/s
  bad-timestamp  00.0/s
  congestion 00.0/s
  ip-option  00.0/s
  proto-cksum00.0/s
  state-mismatch  33380332  869.8/s
  state-insert   00.0/s
  state-limit00.0/s
  src-limit  00.0/s
  synproxy   00.0/s
  translate  00.0/s
  no-route   00.0/s

What does that tell us?

Regards, Lars.

On Wed, Feb 15, 2023 at 9:16 AM Otto Moerbeek  wrote:

> On Tue, Feb 14, 2023 at 11:04:57PM +0100, Lars Bonnesen wrote:
>
> > What can be done to optimize obsd 7.2 running on top of ESXi 7 with
> >
> > 7 vmx "phys" ifs
> > 3 em "phys" ifs
> > 22 virtual ifs
> >
> > Very simply pf ruleset - the box is only running VPN solution between two
> > sites up against a similar configured obsd 7.2
> >
> > I came across https://calomel.org/network_performance.html which has a
> > section concerning obsd 5.1 "and later" - is this also valid for 7.2? I
> did
> > implement the suggestions adapted to the setup, but I can't really see
> any
> > noticeable difference.
>
> This site is genereally regarded as garbage. Do not use it.
>
> >
> > I configured the box with 8 vCPUs and 8 gig RAM and after running for
> some
> > time getting more and more load, I started to face massive package loss
> > both for packages between the two sites but also from the obsd and to the
> > rest of the world. CPU was far from reaching any critical level and loads
> > of memory left
> >
> > I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
> > now seems to hold the packages decently. But for instance when pinging
> > 1.1.1.1, I sometimes get:
> >
> > # ping 1.1.1.1
> > PING 1.1.1.1 (1.1.1.1): 56 data bytes
> > ping: sendmsg: Permission denied
> > ping: wrote 1.1.1.1 64 chars, ret=-1
> > ping: sendmsg: Permission denied
> > ping: wrote 1.1.1.1 64 chars, ret=-1
> > ping: sendmsg: Permission denied
> > ping: wrote 1.1.1.1 64 chars, ret=-1
> > 64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=0.826 ms
> > 64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=0.797 ms
> > 64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=0.799 ms
> >
> > Some permissions denied and then it continues to ping
> >
> > Sometimes when trying to ping a FQDN, I get:
> > ping: no address associated with name
> > as it cannot resolve the name
> >
> > The name is of course registered correctly in DNS.
> >
> > We are planning to put even more load on the setup, but I am not sure
> that
> > 

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Daniele Bonini]

>Date: Wed, 15 Feb 2023 11:08:56 + (UTC)
>From: Jan Stary 
>To: Daniele Bonini 
>Subject: Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility
>
>
> Indeed, although the bad devs working on it, it is a pleasure to use 
> OpenBSD and I will find out an alternative solution
>
>Take you incoherent rants somewhere else.


PS: pls, keep the discussion in the mailing list.

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Daniele Bonini]

Stuart Henderson  wrote:

> We don't have resources to maintain security fixes for EoL'd PHP
> versions beyond what PHP themselves provide

Ok, got it.

> > Worrysome this stuff from my side.. I personally have "tons" of
> > webapps to mantain and there is not a "Docker solution". Is it
> > plausible to come to arrange a "sustainable solution" by the ports,
> > chroot or whatever?
> 
> This is how the web development stack you have chosen works. There are
> others which have better backwards compatibility than PHP.

Let's say like OpenBSD like a PHP dev environment doesn't come 
in handy at time. Try to think if for any reason sysupgrade upgrade
my php system version, they days after I will have no launch for a
while. It is not acceptable..

Indeed, although the bad devs working on it, it is a pleasure to use 
OpenBSD and I will find out an alternative solution offline or
more reasonable online..


-- Daniele Bonini
‎‎

Re: Performance optimizing OpenBSD 7.2

[Hrvoje Popovski]

On 15.2.2023. 10:28, Gábor LENCSE wrote:

> In OpenBSD, the packet forwarding happens single threaded, so the
> performance of your system does not benefit much from the 4 cores.

Hi,

actually if forwarding is single threaded of not, depends of what nic do
you have in box. ix,mcx,bnxt,igc,vmx and maybe others have multiqueue
support and with them you will have better forwarding performance. But
only forwarding performance, not better pf performance or ipsec or
something else...

If you have em(4) you can test em(4) multiqueue diff on tech@
https://marc.info/?l=openbsd-tech=165642186010149=2
but for now em doesn't have multiqueue which means that your forwarding
is single threaded.

For vmware if you have vmx(4) you will have multiqueue support and you
can see that in dmesg and with vmstat

obsd1# dmesg | grep vmx
vmx0 at pci11 dev 0 function 0 "VMware VMXNET3" rev 0x01: msix, 4
queues, address 00:0c:29:b6:ec:81
vmx1 at pci19 dev 0 function 0 "VMware VMXNET3" rev 0x01: msix, 4
queues, address 00:0c:29:b6:ec:8b

obsd1# vmstat -iz | grep vmx
irq114/vmx0 00
irq115/vmx0:0   327060
irq116/vmx0:1   126290
irq117/vmx0:2   123970
irq118/vmx0:3  220
irq123/vmx1 00
irq124/vmx1:0   60
irq125/vmx1:1   20
irq126/vmx1:2   00
irq127/vmx1:3   00


But for now there is problem on machines with lots of cpus and
multiqueue nics and that is number of interrupts.

https://marc.info/?l=openbsd-misc=167472080905265=2

Re: Performance optimizing OpenBSD 7.2

[Claudio Jeker]

On Wed, Feb 15, 2023 at 10:28:57AM +0100, Gábor LENCSE wrote:
> Hi Lars,
> 
> > I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
> > now seems to hold the packages decently.
> 
> As for performance optimization, I think the direction is good, and perhaps
> you could go even further if you have a load balancing device that can
> distribute the traffic among the multiple VMs.

Not sure why reducing the memory should help. Also reducing the number of
virtual CPUs has probably little effect as well. The main point in reducing
the number of cores and disabling threads is to give modern CPUs more
thermal/power headroom to run the fewer CPUs at a higher clockspeed.
I doubt you get the same effect on vCPUs.
 
> In OpenBSD, the packet forwarding happens single threaded, so the
> performance of your system does not benefit much from the 4 cores.

That is not quite correct anymore.

-- 
:wq Claudio

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Stuart Henderson]

On 2023-02-14, Daniele B.  wrote:
> I'm wondering what are your thoughs on the subject of PHP different versions, 
> in respect to OpenBSD lifecycle. And, indeed, what is going to happen in 
> OpenBSD facing this broken compatibility with the past, starting from 8.1.
> Are you going to support PHP 7.4 and 8.0 longer or what?

We don't have resources to maintain security fixes for EoL'd PHP
versions beyond what PHP themselves provide
(https://www.php.net/supported-versions.php).

Current status:

7.4 is no longer getting security fixes. It's kept around for
now because some other ports are using it but I'll probably
be looking at removing it from ports soon. (You can of course
build yourself from source even if it's removed from ports).

8.0 security fixes will stop partway through the OpenBSD 7.3
-stable timeframe (Nov 2023). This is the last version that
will run on OpenBSD/sparc64 unless someone writes code to
support Fibers on the architecture (or we get ucontext
support but that is not very likely).

8.1 is due to have security fixes until Nov 2024 and most
actively maintained PHP projects seem to be working with this
by now.

8.2 has longer support but compatibility is more of a problem,
even some fairly active big projects haven't adapted yet.

> Worrysome this stuff from my side.. I personally have "tons" of  webapps to 
> mantain and there is not a "Docker solution".
> Is it plausible to come to arrange a "sustainable solution" by the ports, 
> chroot or whatever?

This is how the web development stack you have chosen works. There are
others which have better backwards compatibility than PHP.

If you aren't able to keep on top of changes to the PHP language in
your code but do want some backports of fixes, you might be better
off with Debian and repos at https://www.freexian.com/lts/php/ or
https://deb.sury.org/.


-- 
Please keep replies on the mailing list.

Re: Performance optimizing OpenBSD 7.2

[Gábor LENCSE]

Hi Lars,


I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
now seems to hold the packages decently.


As for performance optimization, I think the direction is good, and 
perhaps you could go even further if you have a load balancing device 
that can distribute the traffic among the multiple VMs.


In OpenBSD, the packet forwarding happens single threaded, so the 
performance of your system does not benefit much from the 4 cores.


Best regards,

Gábor

Re: OpenBSD, PHP lifecycle and PHP 8.1 broken compatibility

[Daniele Bonini]

Michael Hekeler  wrote:

> You can run any PHP version you like.
> You can run more than just single version.

ls http://ftp.openbsd.org/pub/OpenBSD/7.2/packages/amd64/ | grep

php-7.4.30p0.tgz   8197515 
php-8.0.23p0.tgz   8771969 
php-8.1.10p0.tgz   9017614


Ok, let's support OpenBSD project by compile whatever PHP version,
right? It's not that easy (c lib and diff dependencies), but it is
nice..

I was waiting for an honest answer against my problematic dev and
testing environment..


-- Daniele Bonini

Re: Performance optimizing OpenBSD 7.2

[Otto Moerbeek]

On Tue, Feb 14, 2023 at 11:04:57PM +0100, Lars Bonnesen wrote:

> What can be done to optimize obsd 7.2 running on top of ESXi 7 with
> 
> 7 vmx "phys" ifs
> 3 em "phys" ifs
> 22 virtual ifs
> 
> Very simply pf ruleset - the box is only running VPN solution between two
> sites up against a similar configured obsd 7.2
> 
> I came across https://calomel.org/network_performance.html which has a
> section concerning obsd 5.1 "and later" - is this also valid for 7.2? I did
> implement the suggestions adapted to the setup, but I can't really see any
> noticeable difference.

This site is genereally regarded as garbage. Do not use it.

> 
> I configured the box with 8 vCPUs and 8 gig RAM and after running for some
> time getting more and more load, I started to face massive package loss
> both for packages between the two sites but also from the obsd and to the
> rest of the world. CPU was far from reaching any critical level and loads
> of memory left
> 
> I downscaled from 8 to 4 vCPUs and from 8 to 4 gig RAM - and the two obsd
> now seems to hold the packages decently. But for instance when pinging
> 1.1.1.1, I sometimes get:
> 
> # ping 1.1.1.1
> PING 1.1.1.1 (1.1.1.1): 56 data bytes
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> ping: sendmsg: Permission denied
> ping: wrote 1.1.1.1 64 chars, ret=-1
> 64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=0.826 ms
> 64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=0.797 ms
> 64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=0.799 ms
> 
> Some permissions denied and then it continues to ping
> 
> Sometimes when trying to ping a FQDN, I get:
> ping: no address associated with name
> as it cannot resolve the name
> 
> The name is of course registered correctly in DNS.
> 
> We are planning to put even more load on the setup, but I am not sure that
> it is a good idea

Hard to say, but this could very well be pf running out of states.
pfctl -s info and look at state-limit and/or src-limit. If you are
natting, also look at translate.

-Otto
> 
> The ESX server has hyperthreading enabled.There are many discussions about
> this, and what I can summarize is that apart from a security perspective,
> hyperthreading should be left enabled
> 
> How to get better performance?
> 
> Regards, Lars.