4 Replies Latest reply on Aug 28, 2010 9:00 PM by Gordie

    FMS 10 Web Publishing (fmswpc.exe) CPU Hit



      FMS 10 Web Publishing (fmswpc.exe) CPU Hit

      Your post

      Hi there,

      Sometimes once a week, sometimes once a day the process fmswpc.exe will spike the CPU's load to 100% and stay there indefinitely.  I have to first end the process via the task manager, then I must stop and restart Web Publishing via the Admin Console.  During the time of the spike, all database usage (e.g. PHP access or Client access) comes to a near standstill and most of my client connections lose communication with the server).  This becomes extremely problamatic if I am not monitoring the CPU load and don't catch the problem right away, or if I'm away from a computer.

      The Admin Console itself does not report a problem during the spikes.

      Similar to the problem, most all requests (especially  "addRecordCommand" via the API for php) will put the CPU to 100%  via  the fmswpc.exe for the duration of the call.  If it's a find  command,  this could take a number of seconds in which the rest of the  database  slows completely.  The problem with this is, if I'm monitoring the task manager's performance graph and I see the CPU load hit 100%, I have to wait to see if it's just a request ending or if it's truly the error rearing its head.

      Visually, durning the error the task manager shows a perfectly flat line at the top of the graph.  When the server "normally" gets hit to 100% during a fmswpc.exe call it will be a jagged line at the top of the graph, although sometimes a "normal" 100% call produces a flat line at the top as well.  I've attached an image to show what I see.

      We're running Windows Server 2003 R2 on an Intex Xeon 2.66GHz with 1.6 GB RAM.

      Our server is FMS v10.0.2.206

      On average we have about 50 clients using the system and one or two CWP (but we have had as many as 50).  The number of CWP connections doesn't seem to cause the CPU error, but if multiple CWP connections perform a task at the same time the 100% CPU hit does render the system very slow until their operations conclude.

      Thank you for any help!



        • 1. Re: FMS 10 Web Publishing (fmswpc.exe) CPU Hit

          You might check this link to see if it has any bearing on what you are observing:

          PHP API : Longer to load a large field instead of 10 smaller ones...

          This is one of many acknowledged bugs that can be found in the Known Bugs List here in the Report an Issue section of the forum.

          It can also be downloaded as a database file from:   http://www.4shared.com/file/8orL8apk/FMP_Bugs.html

          • 2. Re: FMS 10 Web Publishing (fmswpc.exe) CPU Hit

            Thanks Phil,

            I read that post a while ago while researching my problem and I don't know if it's the same thing.  The error I'm getting seems less like a slowdown and more like a "crash" (only without a process stopping on its own).  Unfortunately I haven't been able to truly test if it would ever recover on its own because it would put our server out of comission for much too long.  The times I've had to fix it after crashing it had stayed in the 100% CPU usage state for an unknown amount of time (but in the excess of an hour).

            The other thing that points away from this being the same error is that my PHP layouts have very little data (name, address, date, etc) and only a few have portals (also with minimal data).  Just to be safe though, and to help identify where the crash happens, I eliminated any extraneous data  on each layout and created separate PHP accounts for the separate operations/layouts to see if I can't narrow down where the error occurs. Those without portals are just as guilty (and sometimes moreso) as those with portals.

            So I'm not sure if this would be the same bug or not.  Are there any ideas of when the "Quadratic/Exponential slowdown..." bug will be fixed or other ways to alleviate the problems?

            Thanks again,


            • 3. Re: FMS 10 Web Publishing (fmswpc.exe) CPU Hit

              You should check both your web access log and the log files in the your FileMaker Server/Logs directory to find out which query triggers this behaviour.

              According to our experience, WPE CPU spikes are triggered by search engine bots that request an old page or query again, but in the meantime the data had changed in the DB and therefore the query is not correct anymore. In this case often all the DB records are returned, which leads to the behavior you observed. Careful design of your PHP or XML/XSLT pages can avoid this.

              • 4. Re: FMS 10 Web Publishing (fmswpc.exe) CPU Hit

                Thanks Martin,

                All of the behaviors except the "crash" where the CPU stays at 100% is identifiable.  When I run a specific find, I get the "flat topped" graph (which is repeatable).  It's a pretty big find, but it still runs the CPU at 100%, even though the exact same find via the client hardly makes a tick.  A smaller find will peak to about 75% or so.  The jagged 100% usage is typically a looped AddNewCommand, where new grades are being entered for x number of students (also repeatable).  Again, adding a record via the client requires much less CPU load.  The crash, though, I haven't been able to repeat.  It's in a public space so when the error doesn't occur, I see the result of what the user was doing (and can see things working), but if it does crash I don't know if what they did or didn't do unknowingly... all validations are checked client and server side before entry, etc, and when I run tests in the public area I've never been able to repeat the problem.

                Speaking of the public area: we have already instituted the steps to keep the bots away from our those pages/sites, and any private sites also use PHP to limit access.  I read that was a potential problem, so that was one of the first things I implemented.

                I'd love any info on deciphering the FMS logs because they aren't that helpful to me  other than letting me know which account made a query, which is why I've  made specific accounts for specific functions.  In doing so I've  narrowed the error down to an "area" but nothing specific.  The stumper  is that that area works fine most of the time -- until it errors.   Unfortunately FMS doesn't see it as an error, rather it just reports:  xxx.xxx.xxx.xxx:x - [accountName] "/fmi/xml/resultset.xml" 200 xxxx.  Is  there any way to interpret these log entries in a more plain-text way?   That could be a great help.

                So I guess I'll say that I can identify all of the spikes, just not the crash ones.

                Thanks again!