Design issue Skin build memory leak

Status
Not open for further replies.

Adam Howard

Well-known member
I think I have reported this before, but it was labled as not a bug. Frankly, I think whoever did that is crazy.

If I can have ZERO modifications and only skins (16), make 1 single template edit and be told I've run out of memory after dedicating several GB to php and another several GB to MySQL.

It is a bug. You can call it a feature all you like. It is a bug.

Someone other than staff, please confirm or deny my findings.
 
I've read them. Not an acceptable answer. QUOTE: You have to many skins. :End

  • If a free and open source project can have more skins than a paid product, there is something wrong.
  • If I can provide unrealistic amount of resources to running 1 single script and it uses all of it & still does not complete, there is something wrong.
  • If your competitors ...All of them, not just some, but all... Can complete this task & yours can not, there is something wrong.
 
So changing the packet sizes etc didn't help?
Far beyond what most average would be using.

Already rules out my own personal setup as the cause. Tried on a few other host, just to double check.

There is either a memory leak or the way in which it rebuils its self if flawed. How it happens, why, ect.... Doesn't matter.
  • I'm not the only one who has had this issue and it is on going... ie... BUG.
  • There is several dozen threads dedicated to this issue......ie.... BUG.
  • We all have different setups and it affects many (if not all) ....... ie... BUG.
 
Yeah I hate this. I love designing skins but I can't really install most of my own designs cause of this.

Would transferring all of your template modifications to the TMS (Template Modification System) help?
 
Yeah I hate this. I love designing skins but I can't really install most of my own designs cause of this.

Would transferring all of your template modifications to the TMS (Template Modification System) help?

Unlikely as TMS just plugs into the system that is already there.
 
This is simply how XenForo works. At the best, it's a future fix.

If you have debug mode on, BTW, turn it off. That will use a lot of memory.
 
This is simply how XenForo works. At the best, it's a future fix.

If you have debug mode on, BTW, turn it off. That will use a lot of memory.
It really is a bug no matter how you put it. And it really needs to be fixed.

I can not find any alternative to XenForo .... Free or paid ... That suffers from this bug.
 
1/2 fix

Issue:

"X" amount of template edits causes memory leak (X value varies)

Fix:

Install and use TMS
http://xenforo.com/community/resources/template-modification-system-tms.293/

Successfully "stuffed" on a test site with over 500 individual template edits (492) :eek: (just to see if it could be done). Completed without issue (even on a shared host).

Suggestion:
XenForo builds their own TMS System or purchases the rights to the current one developed.

************************

Issue:

"X" amount of additional themes / skins / styles (whichever you prefer to call them) causes memory leak (X value varies)

Fix:

N/a :cry:

Suggestion:

XenForo resolves their design bug
 
Successfully "stuffed" on a test site with over 500 individual template edits (492) :eek: (just to see if it could be done). Completed without issue (even on a shared host).
Are you using safe rebuild mode together with deleayed compilation in TMS?
If delayed compilation is on modifications do not applied at the save moment. You have to rebuild templates to see changes.
I can extend this option to influence same way on templates. So when you save templates you won't see changes at the moment but after rebuild.
Safe rebuild just decrease atomicity of rebuilding step. Minimal amount operations per step is handling single template_map_id instead of template_id.

Suggestion:
XenForo builds their own TMS System or purchases the rights to the current one developed.
I would be glad to implement it voluntarily if it is allowed :)
 
I was receiving this error with a shared host as well, then I migrated over to http://schmitzit.com/it From there I have not received this error.

I am currently running 7 Different styles upon two defaults in which I do not touch only for upgrades. In each of these 7 styles I have done 200+ template edits. I know for a fact one Style I have done over 500 Template edits, with custom ones as well. I also have over 40 addons installed. Still do not receive this error, anymore. One of the addons I have installed is TMS, but not sure if this was the fix for that error, for which I installed right after I had migrated over to http://schmitzit.com/it

I am not saying you are wrong, I am not saying you are right. I am saying you could have over looked something. Reason I state this is whenever I rebuild my cache and even do template edits upon saving, Cache rebuilds takes approximately 212 seconds, Template saves depends on which styling template I am saving could take 40-160 seconds. I know for a fact that I am using a high amount of resources doing either one, so all I am stating is that you could have overlooked something.
 
Are you using safe rebuild mode together with deleayed compilation in TMS?
If delayed compilation is on modifications do not applied at the save moment. You have to rebuild templates to see changes.
I can extend this option to influence same way on templates. So when you save templates you won't see changes at the moment but after rebuild.
Safe rebuild just decrease atomicity of rebuilding step. Minimal amount operations per step is handling single template_map_id instead of template_id.


I would be glad to implement it voluntarily if it is allowed :)
Actually, I find leaving both boxes un-checked yields better results. (Go figure, huh?)
 
This has been marked as Design Issue and is in the Resolved Bugs Report forum.

There is no point in bumping it as nothing further will be done.

As Mike posted above, at best it will be a future fix.
 
This has been marked as Design Issue and is in the Resolved Bugs Report forum.

There is no point in bumping it as nothing further will be done.

As Mike posted above, at best it will be a future fix.
It is a design issue... That resolves as a bug.

If I can give XenForo 16 GB of dedicated ram and still run into this..... It needs fixing.
 
  • Like
Reactions: DRE
Status
Not open for further replies.
Top Bottom