one of the main reasons to use fixed timestep is because of that FPS variation that everyone have to face, right?
Very roughly speaking, yes. But it's worth explaining a bit more.
You can deal with FPS variation simply by giving your game loop a timer, and every frame you check how much time has passed (the so-called "deltaTime" value), and you pass that information to every component of your game logic. At this point FPS variation is no longer a direct issue.
The indirect issue comes from the fact that your physics engine has to deal with deltaTimes anywhere from one millisecond to ten seconds. The problem is that computing one thousand "physics steps" for one millisecond is not necessarily the same thing as computing a single "physics step" for one second. If an enemy projectile passes through you in a fraction of a second, then they're completely different, and your game is broken. This is the problem that a fixed timestep solves, by letting the deltaTime pile up and then feeding it to the physics engine (and AI and other stuff) in fixed-size chunks. Note that rendering and possibly some cosmetic animations are still done once every frame; it's only game logic that needs to pretend time is discrete to work properly.
Is that a normal behavior with V-Sync enabled?
It can be. Everything time-related is going to have some inherent imprecision, but vsync is different from simply sleeping for 1/xth of a second (which is what setFramerateLimit does). Specifically, vsync is designed to prevent screen tearing by forcing your program to pause until the monitor is ready for a new frame. Even if the monitor refreshes 60 times a second, waiting for the monitor to be ready is different from simply waiting 1/60th of a second. Your program and the monitor are actually being kept in sync, which sometimes means your program has to wait longer than usual. There's a reason most games let the user configure this stuff; the tradeoff between possible screen tearing and possible input lag is not trivial.
If you're interested in more detail, look up double buffering and triple buffering.
Regarding your chart and lag problem...I'm not really sure what to say, since an FPS spike shouldn't mean your program lags. If anything vsync means your program should stop drawing frames until the monitor is ready for a new one, not draw thousands of extra frames for the monitor to ignore. Admittedly, an FPS of several thousand is usually misleading, since that just means one frame got drawn much faster than usual, not that you actually drew 10000 frames in one second. It's probably more meaningful to look at milliseconds per frame than frames per second. Plus, you didn't tell us how you're measuring this, so for all we know maybe the counter you're using gets easily confused by vsync.
How does it look when you try setFramerateLimit(59) instead of vsync?
