-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Row size too large #26
Comments
Hi, this happened to me as well and I agree that changing the MySQL is not a good solution to workaround this problem. What do you think? |
I think an option to store the raw data in the filesystem, with a table in the DB containing the metadata, is a good solution. I'm not as much a fan of restricting level of detail, unless it's a filter that can be applied to the raw data after the fact. I'd rather have everything and filter down to the relevant information, than risk not having relevant info in a capture. |
I think I'll definitely add this feature, but of course there's also a problem with storing files in the filesystem in a multi-server setup. The admin will not have access to the files generated on all nodes (unless you have a shared filesystem, which I don't recommend). But I guess that's how it is then, and in this case you'll have to switch back to the database and increase the MySQL settings. Another thought I had was that the profile data can probably be compressed really well (e.g. using gzcompress). This might allow storing a lot more data before hitting the limit. |
Another way to handle it would be build a generic storage interface that handles retrieving the data, then implement the MySQL storage and FS storage as plugins to that. The metadata could still be stored in a mysql table, with some reference to the storage backing the profile data. This would also allow building plugins to handle specific cases (like a multi-server setup), or other storage backends. |
Had the same problem but needed a quick fix for debugging. So I wrote the call stack to files like said above instead of writing them to the database (I have only one server in my test environment) . Here is my solution (! not for productive environment): I changed
|
When profiling on very heavy pages, the profiler will fail to write its data to the table, and will fail with the following message.
Error while saving Aoe_Profiler data: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
Although this could be fixed by modifying some settings with the InnoDB engine, I would rather not have to do that just to get the profiler working on a page that I'm trying to cut down anyway.
Would it be possible to get an option to use the old way of displaying the AOE Profiler data at the bottom of the page, and bypass writing to the table?
The text was updated successfully, but these errors were encountered: