Navigation

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

    35-45% cpu initization in testing lab

    Hardware
    4
    14
    4975
    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.
    • E
      eyepodder last edited by

      I am experimenting with 1.2-beta 1 on a Celeron 1.7 with 512 megs of ram with no extra packages.

      (1 Wan- Dlink 1Ghz nic),  (1 DMZ - 3com- currently not in use) and (1 LAN - builtin mother board card, I'm not sure of the make off hand but it's in a IBM desktop)

      The cpu hovers around 35-40% with no real traffic except for me configuring the fw and internet testing. This seems high
      to me. I even tried the latest snapshot didn't make a difference.

      Is this normal as it seems high to me.

      One thing to note. It crashed twice. Once when I was configuring the fw from home. I was setting up PPTP and I tested the vpn client. I tested the pptp connection and connected fine. Then I was adding a rule to allow pptp clients access to * and it crashed when I saved the rule. I was still in the pptn connection as well has connected to the fw from the wan ip address when it crashed

      Another time I added the new dashboard and I click on the new states in the new dashboards. The both times it crashed I was configuring the fw from the WAN (connecting from home vs the LAN side in the office). No network errors on either the WAN nor LAN interfaces

      Since I can't connect right now I don't have any memory dumps but I was more concerned with 35-40%

      I reinstalled the fw twice with the same results. Would a nic be causing this problem.

      Thanks,

      1 Reply Last reply Reply Quote 0
      • M
        Matts last edited by

        Hi,

        Have you already updates directly after installing to the latest snapshot ? 06-06-2007 seems to be running fine here.

        Cheers,

        Matt

        1 Reply Last reply Reply Quote 0
        • E
          eyepodder last edited by

          The crashing was down to hardware. I came into the office to see NO OS found. Reboot the machine, same thing NO OS found. Looks like either the HD or motherboard is going. Re-inserted the power and ide cables on the HD/motherboard and it booted. Still can't explain the high 35-40% CPU with no real traffice unless it's related to the drive and or motherboard dying.

          1 Reply Last reply Reply Quote 0
          • P
            Perry last edited by

            From shell you could use the following commands
            systat
            top -S
            systat -vm 1
            to trace a bottleneck. Also remove the dlink as the 3com might be better supported.

            1 Reply Last reply Reply Quote 0
            • E
              eyepodder last edited by

              I replaced the HD and the CPU % has dropped down to 5-7% from 35-45%. I guess a bad HD increases CPU load quite a bit. LOL ::)

              What's wrong with the Dlink card? It's a 1 Gig card. I was going to replace the LAN and DMZ cards with them as I was planning of having a webserver (fronted)in the DMZ and a MySql server in the LAN side for protection so I figured that faster cards between to DMZ and LAN would be better and stick with the 3com and the WAN side.

              1 Reply Last reply Reply Quote 0
              • P
                Perry last edited by

                Intel and 3com should in general have better written drivers for Freebsd, by that means lower cpu usages. So it could be worth a test imo.

                1 Reply Last reply Reply Quote 0
                • E
                  eyepodder last edited by

                  It's back up to 35%-40%. When I did a top -S I see that syslogd hovering around 17-18% and the STATE is SELECT.

                  Why is syslogd so high is that normal?

                  1 Reply Last reply Reply Quote 0
                  • M
                    Matts last edited by

                    @Perry:

                    Intel and 3com should in general have better written drivers for Freebsd, by that means lower cpu usages. So it could be worth a test imo.

                    Is the same for their Desktop Version ?

                    I normally use always Intel because it's default supported by most distro's.

                    But are there advantages comparing to the server versions ?

                    1 Reply Last reply Reply Quote 0
                    • P
                      Perry last edited by

                      t's back up to 35%-40%. When I did a top -S I see that syslogd hovering around 17-18% and the STATE is SELECT.

                      Why is syslogd so high is that normal?

                      Do you have log on your rules?

                      1 Reply Last reply Reply Quote 0
                      • E
                        eyepodder last edited by

                        No logs on the rules.

                        1 Reply Last reply Reply Quote 0
                        • E
                          eyepodder last edited by

                          Figure it out. Went back into the system log settings and noticed that I had turned on

                          Log packets blocked by the default rule
                          Hint: packets that are blocked by the implicit default block rule will not be logged anymore if you uncheck this option. Per-rule logging options are not affected.

                          As soon as I deslected it syslogd dropped to barely a reading..

                          1 Reply Last reply Reply Quote 0
                          • M
                            Matts last edited by

                            @eyepodder:

                            Figure it out. Went back into the system log settings and noticed that I had turned on

                            Log packets blocked by the default rule
                            Hint: packets that are blocked by the implicit default block rule will not be logged anymore if you uncheck this option. Per-rule logging options are not affected.

                            As soon as I deslected it syslogd dropped to barely a reading..

                            I also have that on, so that's already an issue. OK :)

                            1 Reply Last reply Reply Quote 0
                            • P
                              Perry last edited by

                              Figure it out. Went back into the system log settings and noticed that I had turned on

                              It's on by default and without using cpu

                              What i would do is as following. (with a default install)

                              Replacing ram, cpu,  motherboard if you got any spare stuff in the lap.
                              try a different freebsd version using pfsense 1.01 and m0n0wall.
                              last resort use another pc.

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

                                Yeah logging packets blocked by the default rule certainly shouldn't use ~20% CPU unless you're getting hammered by something that's getting blocked.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post

                                Products

                                • Platform Overview
                                • TNSR
                                • pfSense
                                • Appliances

                                Services

                                • Training
                                • Professional Services

                                Support

                                • Subscription Plans
                                • Contact Support
                                • Product Lifecycle
                                • Documentation

                                News

                                • Media Coverage
                                • Press
                                • Events

                                Resources

                                • Blog
                                • FAQ
                                • Find a Partner
                                • Resource Library
                                • Security Information

                                Company

                                • About Us
                                • Careers
                                • Partners
                                • Contact Us
                                • Legal
                                Our Mission

                                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                Subscribe to our Newsletter

                                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                © 2021 Rubicon Communications, LLC | Privacy Policy