Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

Hi Dan! Thanks for all the work you're doing on OmniOS! > > On Oct 22, 2015, at 1:11 PM, Dan McDonald > > wrote: > > > > "pkg update" followed by "svcadm restart ntp" as a safety measure > > should be sufficient. No rebooting is needed. > > I made a small mistake here. The

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

Are you using the same record size of 4K on your zfs pool as you used with your linux test system? If the record size for the zpool and slog is set at the default value of 128K, it will greatly reduce the measured IOPS relative to that measured with a recordsize of 4K. Min Kim > On Oct

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

Interesting… Although, I’m not sure if this is really the problem. For test, I booted up linux and put both ZeusRAM to raid1 software raid and repeated the test. I got full 48kIOPS in the test, meaning there was 96kIOPS sent to JBOD (48k IOPS for each drive). On the OmniOS test bed, there are

Re: [OmniOS-discuss] ILB memory leak?

On 21/10/2015 17:35, Dan McDonald wrote: On Oct 21, 2015, at 6:08 AM, Al Slater wrote: Hi, I am running omnios r151014 on a couple of machines with a couple of zones each. 1 zone runs apache as an SSL reverse proxy, the other runs ILB for load balancing web to app tier

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

The ZIL on log devices suffer a bit from not filling queues well. In order to get the queues to fill more, try running your test to several zfs folders on the pool simultaneously and measure your total I/O. As I understand it, ff you're writing to only one zfs folder, your queue depth will stay

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

On Thu, 22 Oct 2015, Matej Zerovnik wrote: If I create a new raidz2 pool with 10 hard drives, mirrored ZeusRAMs for ZIL and set sync=always, I can only squeeze 14k IOPS out of the system. Is that normal or should I be getting 48k IOPS on the 2nd pool as well, since this is the performance

Re: [OmniOS-discuss] OmniOS backup box hanging regularly

On Thu, Oct 22 2015 20:51:32 +0200, Jim Klimov wrote: > Did anyone run into issues with many zfs-auto-snapshots (e.g. > thousands - many datasets and many snaps until they are killed to keep > some 200gb free) on a small nujber of spindles? Not with that number of snapshots, but we had several

[OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

The NTP software was updated to 4.2.8p4 yesterday. I've pushed out updates for r151006, r151014, and bloody. As I mentioned earlier, r151012 users should update to r151014. "pkg update" followed by "svcadm restart ntp" as a safety measure should be sufficient. No rebooting is needed. NTP's

Re: [OmniOS-discuss] OmniOS backup box hanging regularly

Hi Tovarishch Jim, I had similar issue with my box and it was related to the NFS locks. I assume you are using it due to the Linux backups. The solution was posted by Chip on the mailing list. Copy of his solution below: "I've seen issues like this when you run out of NFS locks. NFSv3 in

[OmniOS-discuss] Slow performance with ZeusRAM?

Hello, I'm building a new system and I'm having a bit of a performance problem. Well, its either that or I'm not getting the whole ZIL idea:) My system is following: - IBM xServer 3550 M4 server (dual CPU with 160GB memory) - LSI 9207 HBA (P19 firmware) - Supermicro JBOD with SAS expander - 4TB

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

I believe this is an known issue with SAS expanders. Please see here: http://serverfault.com/questions/242336/sas-expanders-vs-direct-attached-sas When you are stress-testing the Zeusram by itself, all the IOPs and

Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

On Thu, Oct 22 2015 20:57:45 +0200, Volker A. Brandt wrote: > Thanks for all the work you're doing on OmniOS! > > > > On Oct 22, 2015, at 1:11 PM, Dan McDonald > > > wrote: > > > > > > "pkg update" followed by "svcadm restart ntp" as a safety measure > > > should be

Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

> On Oct 22, 2015, at 1:11 PM, Dan McDonald wrote: > > "pkg update" followed by "svcadm restart ntp" as a safety measure should be > sufficient. No rebooting is needed. I made a small mistake here. The "svcadm restart..." is not necessary, the IPS package does the right

Re: [OmniOS-discuss] OmniOS backup box hanging regularly

22 октября 2015 г. 19:36:56 CEST, Yavor Tomov пишет: >Hi Tovarishch Jim, > >I had similar issue with my box and it was related to the NFS locks. I >assume you are using it due to the Linux backups. The solution was >posted >by Chip on the mailing list. Copy of his solution

Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

On Thu, Oct 22, 2015 at 2:57 PM, Volker A. Brandt wrote: >> I made a small mistake here. The "svcadm restart..." is not >> necessary, the IPS package does the right thing here. > > Well, no, it doesn't. :-) That's due to a design flaw in the interaction > between IPS and SMF

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

I’m using the default value of 128K on linux and OmniOS. I tried with recordsize=4k, but there is no different in iops… Matej > On 22 Oct 2015, at 21:36, Min Kim wrote: > > Are you using the same record size of 4K on your zfs pool as you used with > your linux test

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

On Thu, 22 Oct 2015, Matej Zerovnik wrote: I’m using the default value of 128K on linux and OmniOS. I tried with recordsize=4k, but there is no different in iops… There should be a large difference unless the file data is already cached in the ARC. Even with caching, a block size of 128k

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

Chip: I tried running fio on multiple folders and it’s a little better When I run 7x fio (iodepth=4 threads=4), I get 28k IOPS on average When I run 7x fio (iodepth=4 threads=16), I get 35k IOPS on average. iostat shows that there is transfer rate of 140-220MB/s with average request size of

Re: [OmniOS-discuss] Slow performance with ZeusRAM?

On Thu, 22 Oct 2015, Matej Zerovnik wrote: Bob: Yes, my ZFS is ashift=12, since all my drives report 4k blocks (is that what you ment?). The pool is completly empty, so there is enough place for writes, so write speed should not be limited because of COW. Looking at iostat, there are no reads

Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

Lauri Tirkkonen writes: > > Well, no, it doesn't. :-) That's due to a design flaw in the > > interaction between IPS and SMF (IMHO). [...] > Well, that's not a design flaw. Actuators are executed only when the > action (eg. file) specifying them changes Yes, this is how IPS does it. IPS does

Re: [OmniOS-discuss] UPDATE NOW --> ntp to 4.2.8p4

Eric Sproul writes: > The service has restarted correctly for me on both 006 and 014 with > this update. I'm not sure why that is though, because you're > correct that the ntp.xml file has not changed in all of the '014 > versions published. I was under the impression that the > restart_fmri

Re: [OmniOS-discuss] OmniOS backup box hanging regularly

Chip was responding to an issue that we have been having (since 9/18) with our online systems becoming unresponsive to NFS and CIFS. During these hangs we also see that doing an “ls” works, but an “ls –l” hangs. NFS cannot be restarted, and we are forced to reboot. I was hopeful that the NFS

Re: [OmniOS-discuss] ILB memory leak?

Al Slater writes: > On 21/10/2015 17:35, Dan McDonald wrote: >> >> That should enable user-level memory debugging. If you get a >> coredump, save it and share it. If you don't and the ilb daemon >> keeps running, eventually please: >> >> gcore `pgrep ilbd` >> >> and share THAT corefile. You

[OmniOS-discuss] OmniOS backup box hanging regularly

Hello all, I have this HP-Z400 workstation with 16Gb ECC(should be) RAM running OmniOS bloody, which acts as a backup server for our production systems (regularly rsync'ing large files off Linux boxes, and rotating ZFS auto-snapshots to keep its space free). Sometimes it also runs replicas of