With the RC3 module enabled on a D6 sandbox site, I keep exceeding the PHP script limit everytime I try to view a user account/profile ('Allowed memory size of X bytes exhausted (tried to allocate Y bytes)' - see http://drupal.org/node/76156) . No idea why, or if there is a conflict with other modules (I have way too many on my 'play' site to list here), but thought it may be worth flagging up as a potential problem. PHP limit was increased to 256M (way too big for a production site) and stopped tweaking php.ini et al at that.

I'll try to investigate conflicts with other modules, but it may be a few weeks before I get enough free time to do a thorough look. If anyone else identifies a module conflict, please post here.

Top module by the way.

Comments

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

I can't imagine why this module would do that. I certainly don't see the problem.

snorkers’s picture

snorkers commented

I've no idea why either - but I disabled the RealName module and the problem vanished. I suspect the problem lies elsewhere - either something in my configuration, or another module.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

This is a relatively simple and small module, so I can't imagine how it would use that much memory. Have you looked at core issues that I might accidentally falling into?

snorkers’s picture

snorkers commented

I recently deactivated Calendar and Event modules and the problem vanished immediately. I don't think there's a direct clash between these modules and RealName... but I'll keep looking. Event is still at DEV, and Calendar is currently at RC.

rmiddle’s picture

rmiddle commented

Events isn't to bad on memory but calendar with it hooks into views uses a lot of memory so using it with realnames can move you over the limit. Sometimes something small will cause it.

Thanks
Robert

ianchan’s picture

ianchan commented

Are you using PHP 5.2+? Date/Calendar runs a lot faster when using PHP5.2+ instead of 5.1.

sjf’s picture

sjf commented

I have a similar problem with images. Whenever I try to view a page with inline images, the images fail to display and I get 50MB core dump files in my Drupal root directory (one for every image on the page). This only happened after I installed Real Name and if I remove the module, the problem disappears.

I'm using shared hosting - luckily not with GoDaddy or I'd have a $6000 bill right now :) - PHP 5.2.6, latest versions of D6 core and all modules. Perhaps the core dump files are due to a misconfiguration with the GD2 settings but there is obviously some kind of conflict here. The images are being created with imagecache, but even without it the problem persists. I have the latest dev of Date, but don't have either Event or Calendar installed.

Let me know if I can provide any more info.

MGN’s picture

MGN commented

I think I am also seeing this problem (as originally described by rgcarr) - apache seg faults and white screen of death when trying to view user account (My Account). It goes away as soon as RealName is disabled, but I am not using calendar or event.

But there is more - I only see this problem with about half the users on my test site (user/3 , user/4, and user/5 all show the problem, but user/1 , user/6 , and user/7 do not...). I also notice that if I append /view to the path (i.e. user/3/view) - it works fine without a problem for all users...

Finally, I am also only seeing the problem on a contributed theme...it goes away when I switch to a core theme like bluemarine or garland.

So its definitely a combination of factors...not sure why RealName is at the center of it, but I'll follow up if I get any more leads...

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Active » Postponed (maintainer needs more info)

I have one site using the A3 Atlantis theme and this is working fine (as a matter of fact the Content Profile stuff was developed on that site). My other sites all use core themes. I do not use Event and Calendar.

@rgcarr: do those modules use the user name somewhere?

snorkers’s picture

snorkers commented
Title: Killing PHP Memory Limit » Killing PHP Time Limit

Still finding my way around under the Drupal 'hood' right now, and I erroneously reported it as an memory issue, but the problem seems to be time related (exceeds script limit). I've spent ages trying to recreate the problem with RealName on a another system (#2) and - 'hate' to say it - module works fine ;). Have set both systems to Garland following @MGN's suggestions.

I've looked at loads of modules (turning them on and off), and thought there may be a connection between a few OG modules (RSVP etc) and modules like Signup... which would have impacted on RealName, but having disabled practically every module, I still get the script limit error on my #1 installation:

Fatal error: Maximum execution time of 30 seconds exceeded in /Users/rgcarr/Sites/drupal6/includes/database.mysqli.inc on line 108

Warning: MySQL server has gone away query: dblog_watchdog /* rgcarr : dblog_watchdog */ INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:344:\"Lost connection to MySQL server during query\nquery: sess_write\n/* rgcarr : sess_write */ UPDATE sessions SET uid = 1, cache = 0, hostname = '127.0.0.1', session = 'updates_remaining|a:0:{}node_overview_filter|a:0:{}user_overview_filter|a:0:{}', timestamp = 1232085292 WHERE sid = 'e968795724147c17705b60d6a69bd990'\";s:5:\"%file\";s:48:\"/Users/rgcarr/Sites/drupal6/includes/session.inc\";s:5:\"%line\";i:68;}', 3, '', 'http://drupal6/users/rgcarr', 'http://drupal6/admin/build/modules', '127.0.0.1', 12320 in /Users/rgcarr/Sites/drupal6/includes/database.mysqli.inc on line 128

(Dump just in case this is of any help...?)

So I'm none the wiser as to what the problem is: on the '#1' system my module configuration means that the script limit is exceeded when trying to access User Accounts with RealName enabled; once RealName is disabled, everything's fine. On my '#2' system (same module set enabled), system is fine with or without RealName.

So the only conclusion I've reached so far is that it's probably not directly a module issue, but more likely to be a site/module configuration problem. So I'll keep investigating, and in the meantime I'm trying to keep system #2 alive as it's looking good for user testing!

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Ahh. I ran across a core issue with this same message in watchdog. So, I'm going to guess that you are running InnoDB on a Windows system. There is clearly a bug somewhere outside the RealName module (either core or MySql itself) with InnoDB. I would first recommend turning off InnoDB for at least watchdog and which ever profile tables you are using. On my Windows test machine turning InnoDB on completely destroys my database, so my whole db is MyIsam.

snorkers’s picture

snorkers commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Double ahh! It was starting to look like a much more fundamental problem than your module. I'll do some more investigation and probably leave a solution somewhere else on d.o.
The crashing installation was actually on the Leopard stock installation of MySQL - however, my production site will be on a Windows server, so will bear in mind your recommendations.
Thanks again - I changed this to closed as it's not really a RealName issue, and there's no other relevant forum to post this under just yet.

PS - Found some detail on http://rsaddington.wordpress.com/2007/11/22/optimising-mysql-for-drupal/

By default Drupal uses MyISAM tables which only allow locking on a per table basis. For large community sites with many contributers only one INSERT or UPDATE request can be performed at a time. InnoDB locks at row level allowing multiple updates to a table.This will increase page load times as MySQL will not have to wait until a table is unlocked before performing an INSERT or UPDATE. However indexing in InnoDB causes an overhead on SELECTS, read all about it here: http://2bits.com/articles/mysql-innodb-performance-gains-as-well-as-some...
nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Closed (fixed) » Fixed

let's leave this so people might see it

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.