Hi i noticed the ticket just opened I wanted to address your comment about the piwik and GA disparity.
What i first recommend you do is the following.
1 pick a time frame like a day or 2.
2 run a complete pages report from piwik then save an excel file of it.(This will list all pages and PVs for each)
3 Run a complete GA pages save an excel file report for the exact same time frame (again use PVs for each)
Now compare the the 2 excel files. Look for differences as far as pages that are or arent reporting from one or the other. I helped someone else where they found they had forgotten a complete section to add piwik code to.(im hoping the same is the case here). It will never be exact but they should be relatively close.
You mention you are using a VPS, the web interface is it just the piwik login via a web browser you refer to as being the spike?
If you are logging into your VPS then running the admin you actually may be causing the CPU spike via the VPS interface itself, things like Cpanel or Plesk in themselves are or can be very CPU intensive as they are a complete gui on top of the linux system itself. Is there any way you set a CPU usage measure of the VPS to run, then logout of the VPS interface then wait 10 mins and try to login via the web admin in your piwik install then once done login back into the VPS and see the history?
I am hoping this at least eliminates the overhead that the GUI is causing the spike and not so much the piwik admin.
This was a comment from another user and it reminded me of this CPU usage increase might not hurt to try. Good Luck
An Ubuntu bug [c] was consequently filed on Launchpad. The primary effect is high CPU load in kernel as well as user processes.
This bug affects all supported versions of Ubuntu. Note that this bug is very widespread, impacting almost all modern Linux operating systems.
A fix is currently being prepared for this issue. As a workaround for affected systems, either of the following actions should alleviate the CPU load:
Execute the following command as root (or prepend ‘sudo’ if non-root):
date -u -s “$(date -u -R)”
OR
Reboot
The permanent fix will be in the kernel well before the next leap second (as yet unannounced), which will be a minimum of six months away most likely in 2015.
Do not hesitate to contact Canonical Support if you require further help. You can do this via a support case within Landscape (https://landscape.canonical.com) or by phone (numbers listed in Landscape).