Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    (SOLVED) AMD 64 6/13 snapshot failing after approx 4 hours

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    21 Posts 6 Posters 12.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wallacebw
      last edited by

      Thanks.. I will check once I'm onsite later today.  (luckily, this is in a lab environment and not prod).

      If I add this via /boot/loader.conf.local, it should persist a reboot, but not an upgrade, correct?

      Looking at the freeBSD tuning guide (http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html) they recommend a max of 32K

      We recommend values between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter as it could lead to a boot time crash.

      I'm not worried about memory, so I may set it to 64K (65536) which would consume 128MB of ram.  This should not be an issue as this server has 24GB (it's overkill, but it's what we had laying around that I could use in a lab… One of the advantages of working in a large shop  ;))

      1 Reply Last reply Reply Quote 0
      • G
        Gloom
        last edited by

        lol and here was me thinking my 16Gb was OTT

        Yes loader.conf.local will survive a reboot.

        The handbook is a little conservative in it's values. Assuming you are running the 64bit build and have the physical memory it's safe to take it up quite a bit higher with the 8.x versions of FreeBSD.

        Never underestimate the power of human stupidity

        1 Reply Last reply Reply Quote 0
        • W
          wallacebw
          last edited by

          I was able to work on this today and have made the following changes:

          Upgraded to today's snapshot:  (6/14)

          ran sysctl kern.ipc.nmbclusters=65536

          edited /boot/loader.conf and replaced

          kern.ipc.nmbclusters="0"
          with
          kern.ipc.nmbclusters="65536"

          I am watching the netstat -m outbut and have seen no denied mbuf allocations (although I did not see any before the change either).

          1 Reply Last reply Reply Quote 0
          • W
            wallacebw
            last edited by

            I don't want to call it fixed yet… but so far, so good.  Will update tomorrow.

            Dumb question... is there any reason I couldn't add this to "System: Advanced: System Tunables" as a manual entry if it proves to be stable similar to the following?

            And Thank you all for the help!

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              @wallacebw:

              Dumb question… is there any reason I couldn't add this to "System: Advanced: System Tunables" as a manual entry if it proves to be stable similar to the following?

              that's only for sysctls, not loader items.

              1 Reply Last reply Reply Quote 0
              • C
                clarknova
                last edited by

                I ran kern.ipc.nmbclusters="131072" on an amd64 machine with 4GB RAM with no problem, due to mbuf numbers steadily climbing. When your mbuf number hits the set value of that variable, everything stops.

                db

                1 Reply Last reply Reply Quote 0
                • W
                  wallacebw
                  last edited by

                  @CMB:

                  Understood, but if these sysctls commands are executed at startup, wouldn't this effectively have the same impact for this particular entry given that the buffers don't fill up that quickly and can be modified post-boot?

                  I would like to have it in the config so that If i forget to modify the loader after an upgrade, the setting still gets applied.

                  1 Reply Last reply Reply Quote 0
                  • G
                    Gloom
                    last edited by

                    It used to work several months ago when you added it in there then it stopped for some reason I can't remember, there is a post about it you might be able to find. So now I just stick it in /boot/loader.conf.local and remember to set it after each update.

                    Never underestimate the power of human stupidity

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      If you put it in /boot/loader.conf.local it should get copied across an update automatically.

                      Steve

                      1 Reply Last reply Reply Quote 0
                      • W
                        wallacebw
                        last edited by

                        @stephenw10:

                        If you put it in /boot/loader.conf.local it should get copied across an update automatically.

                        Steve

                        I just tested and can confirm.  Good info… Thanks!
                        This should make it into the next guide book.  I didn't see any mention of it in the 1.2.3 book.

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallacebw
                          last edited by

                          I updated the first port with issue details and resolution steps.  please feel free to let me know if I have any inaccuracies / bad advice listed.

                          Thanks again.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.