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

35-45% cpu initization in testing lab

Scheduled Pinned Locked Moved Hardware
14 Posts 4 Posters 5.6k 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.
  • E
    eyepodder
    last edited by Jun 17, 2007, 11:50 AM

    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 Jun 17, 2007, 12:32 PM

      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 Jun 17, 2007, 1:46 PM

        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 Jun 17, 2007, 5:38 PM Jun 17, 2007, 3:48 PM

          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.

          /Perry
          doc.pfsense.org

          1 Reply Last reply Reply Quote 0
          • E
            eyepodder
            last edited by Jun 18, 2007, 12:35 PM

            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 Jun 18, 2007, 12:53 PM

              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.

              /Perry
              doc.pfsense.org

              1 Reply Last reply Reply Quote 0
              • E
                eyepodder
                last edited by Jun 18, 2007, 3:08 PM

                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 Jun 18, 2007, 4:42 PM

                  @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 Jun 18, 2007, 4:55 PM

                    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?

                    /Perry
                    doc.pfsense.org

                    1 Reply Last reply Reply Quote 0
                    • E
                      eyepodder
                      last edited by Jun 18, 2007, 5:28 PM

                      No logs on the rules.

                      1 Reply Last reply Reply Quote 0
                      • E
                        eyepodder
                        last edited by Jun 20, 2007, 12:27 AM

                        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 Jun 20, 2007, 12:45 AM

                          @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 Jun 20, 2007, 6:59 AM

                            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.

                            /Perry
                            doc.pfsense.org

                            1 Reply Last reply Reply Quote 0
                            • C
                              cmb
                              last edited by Jun 22, 2007, 1:33 AM

                              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
                              14 out of 14
                              • First post
                                14/14
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                This community forum collects and processes your personal information.
                                consent.not_received