high-rate queries
Hi All,*
Is there any reason, workaround for the 389DS about high-rate queries?Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure.The 389DS has 2 cores with 2GB of ram, related settigns are the following: # Open file descriptors* * * * *- * * * *nofile * * * *28192 # sysctl parametersnet.ipv4.tcp_keepalive_time = 120net.ipv4.tcp_keepalive_intvl = 5net.ipv4.tcp_keepalive_probes = 2 After I restarting the service, everything is going fine for a while.OS: Centos 5.5 Any recommendations? --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
Hi Karoly,
You give very little information to go by… it might help to provide log files error and maybe access. Try different loglevels for the error log and explain in a bit more detail what is going wrong with your installation. Â* Regards Â* From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Karoly Czovek Sent: 28 March 2011 10:45 To: 389-users@lists.fedoraproject.org Subject: [389-users] high-rate queries Â* Hi All,Â* Â* Â* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam Â* After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. The 389DS has 2 cores with 2GB of ram, related settigns are the following: Â* Â* # Open file descriptors * Â* Â* Â* Â*- Â* Â* Â* Â*nofile Â* Â* Â* Â*28192 Â* # sysctl parameters net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 5 net.ipv4.tcp_keepalive_probes = 2 Â* Â* After I restarting the service, everything is going fine for a while. OS: Centos 5.5 Â* Â* Any recommendations? Â* Â* --Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.com Â* Â* Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
Ok. Migrating from openldap with 4 slave replicas to 389DS,so i am new in the world of 389DS but my boss is forcing it cos have nice UI ;)
Where i can check for verbose error logs or increase log level? On Mar 28, 2011, at 12:26 PM, Gerrard Geldenhuis wrote:Hi Karoly,You give very little information to go by… it might help to provide log files error and maybe access. Try different loglevels for the error log and explain in a bit more detail what is going wrong with your installation.Â*RegardsÂ*From:Â*389-users-bounces@lists.fedoraproject.orgÂ*[mailto:389-users-bounces@lists.fedoraproject.org]Â*On Behalf OfÂ*Karoly Czovek Sent:Â*28 March 2011 10:45 To:Â*389-users@lists.fedoraproject.org Subject:Â*[389-users] high-rate queriesÂ*Hi All,Â*Â*Â*Is there any reason, workaround for the 389DS about high-rate queries?Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pamÂ*After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure.The 389DS has 2 cores with 2GB of ram, related settigns are the following:Â*Â*# Open file descriptors* Â* Â* Â* Â*- Â* Â* Â* Â*nofile Â* Â* Â* Â*28192Â*# sysctl parametersnet.ipv4.tcp_keepalive_time = 120net.ipv4.tcp_keepalive_intvl = 5net.ipv4.tcp_keepalive_probes = 2Â*Â*After I restarting the service, everything is going fine for a while.OS: Centos 5.5Â*Â*Any recommendations?Â*Â*--Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.comÂ*Â*Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan fromÂ* MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users --Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
Hi Karoly,
When you run the 389-console and double click on the Directory Server component of you installation you will have the ability to change the loglevel. Select the configuration tab and then select access log. That will show you were the access log is stored. You can also select error log and select the log levels that you want to see monitored. You can select multiple levels at once. Â* Additional I would recommend enabling the Audit Log before you change any of the above as that will tell you how to make the changes using LDIF files and thus not needing the GUI. Â* Hope that helps. Â* Regards Â* From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Karoly Czovek Sent: 28 March 2011 11:35 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] high-rate queries Â* Ok. Migrating from openldap with 4 slave replicas to 389DS, so i am new in the world of 389DS but my boss is forcing it cos have nice UI ;) Â* Where i can check for verbose error logs or increase log level? Â* Â* On Mar 28, 2011, at 12:26 PM, Gerrard Geldenhuis wrote: Hi Karoly, You give very little information to go by… it might help to provide log files error and maybe access. Try different loglevels for the error log and explain in a bit more detail what is going wrong with your installation. Â* Regards Â* From:Â*389-users-bounces@lists.fedoraproject.orgÂ*[mailto:389-users-bounces@lists.fedoraproject.org]Â*On Behalf OfÂ*Karoly Czovek Sent:Â*28 March 2011 10:45 To:Â*389-users@lists.fedoraproject.org Subject:Â*[389-users] high-rate queries Â* Hi All,Â* Â* Â* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam Â* After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. The 389DS has 2 cores with 2GB of ram, related settigns are the following: Â* Â* # Open file descriptors * Â* Â* Â* Â*- Â* Â* Â* Â*nofile Â* Â* Â* Â*28192 Â* # sysctl parameters net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 5 net.ipv4.tcp_keepalive_probes = 2 Â* Â* After I restarting the service, everything is going fine for a while. OS: Centos 5.5 Â* Â* Any recommendations? Â* Â* --Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.com Â* Â* Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan fromÂ* MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users Â* --Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.com Â* Â* Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
OK, found it.Disabled the restart cronjob, let me see what happens... error log was set to connections, i guessi'll need loglevel.
Any idea, what settings i need basicly @server side, with so 'high' connection rate? On Mar 28, 2011, at 3:46 PM, Gerrard Geldenhuis wrote:Hi Karoly,When you run the 389-console and double click on the Directory Server component of you installation you will have the ability to change the loglevel. Select the configuration tab and then select access log. That will show you were the access log is stored. You can also select error log and select the log levels that you want to see monitored. You can select multiple levels at once.Â*Additional I would recommend enabling the Audit Log before you change any of the above as that will tell you how to make the changes using LDIF files and thus not needing the GUI.Â*Hope that helps.Â*RegardsÂ*From:Â*389-users-bounces@lists.fedoraproject.orgÂ*[mailto:389-users-bounces@lists.fedoraproject.org]Â*On Behalf OfÂ*Karoly Czovek Sent:Â*28 March 2011 11:35 To:Â*General discussion list for the 389 Directory server project. Subject:Â*Re: [389-users] high-rate queriesÂ*Ok. Migrating from openldap with 4 slave replicas to 389DS,so i am new in the world of 389DS but my boss is forcing it cos have nice UI ;)Â*Where i can check for verbose error logs or increase log level?Â*Â*On Mar 28, 2011, at 12:26 PM, Gerrard Geldenhuis wrote: Hi Karoly,You give very little information to go by… it might help to provide log files error and maybe access. Try different loglevels for the error log and explain in a bit more detail what is going wrong with your installation.Â*RegardsÂ*From:Â*389-users-bounces@lists.fedoraproject.orgÂ*[mailto:389-users-bounces@lists.fedoraproject.org]Â*On Behalf OfÂ*Karoly Czovek Sent:Â*28 March 2011 10:45 To:Â*389-users@lists.fedoraproject.org Subject:Â*[389-users] high-rate queriesÂ*Hi All,Â*Â*Â*Is there any reason, workaround for the 389DS about high-rate queries?Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pamÂ*After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure.The 389DS has 2 cores with 2GB of ram, related settigns are the following:Â*Â*# Open file descriptors* Â* Â* Â* Â*- Â* Â* Â* Â*nofile Â* Â* Â* Â*28192Â*# sysctl parametersnet.ipv4.tcp_keepalive_time = 120net.ipv4.tcp_keepalive_intvl = 5net.ipv4.tcp_keepalive_probes = 2Â*Â*After I restarting the service, everything is going fine for a while.OS: Centos 5.5Â*Â*Any recommendations?Â*Â*--Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.comÂ*Â*Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan fromÂ* MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-usersÂ*--Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.comÂ*Â*Â* __________________________________________________ ______________________ In order to protect our email recipients, Betfair Group use SkyScan fromÂ* MessageLabs to scan all Incoming and Outgoing mail for viruses. __________________________________________________ ______________________ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users --Â* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& Â*Central Asia - Middle East& Â*Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:Â*karoly.czovek@moveoneinc.com web:Â*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
On 03/28/2011 03:45 AM, Karoly Czovek wrote:
Hi All,* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam What version of 389-ds-base?* 32-bit or 64-bit? After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. What are the exact client error codes/messages?* Any errors in the dirsrv errors log?* Can you post excerpts of the dirsrv access log from around the time of the client errors? The 389DS has 2 cores with 2GB of ram, related settigns are the following: # Open file descriptors * * * * *- * * * *nofile * * * *28192 # sysctl parameters net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 5 net.ipv4.tcp_keepalive_probes = 2 see http://directory.fedoraproject.org/wiki/Performance_Tuning#Linux After I restarting the service, everything is going fine for a while. OS: Centos 5.5 Any recommendations? --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
the server is 32bit, the exact client error message is cannot connect to the server.(even ldapsearch cant). let me check the logs once appearing the errors again,now disabled the restart cronjob.
On Mar 28, 2011, at 4:16 PM, Rich Megginson wrote: On 03/28/2011 03:45 AM, Karoly Czovek wrote: Hi All,* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam What version of 389-ds-base?* 32-bit or 64-bit? After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. What are the exact client error codes/messages?* Any errors in the dirsrv errors log?* Can you post excerpts of the dirsrv access log from around the time of the client errors? The 389DS has 2 cores with 2GB of ram, related settigns are the following: Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
On 03/28/2011 08:29 AM, Karoly Czovek wrote:
the server is 32bit, the exact client error message is cannot connect to the server. But what is the error code?* 80?* 81?* 91?* If you can reproduce with ldapsearch, in the shell, $? should hold the error code (even ldapsearch cant). let me check the logs once appearing the errors again, now disabled the restart cronjob. On Mar 28, 2011, at 4:16 PM, Rich Megginson wrote: On 03/28/2011 03:45 AM, Karoly Czovek wrote: Hi All,* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam What version of 389-ds-base?* 32-bit or 64-bit? After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. What are the exact client error codes/messages?* Any errors in the dirsrv errors log?* Can you post excerpts of the dirsrv access log from around the time of the client errors? The 389DS has 2 cores with 2GB of ram, related settigns are the following: Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
i can reproduce, but the server is in production.if the clients got this error then i also unable to connect with ldapsearch.
just now appeared, i have full verbose trace logs, but nothin intrestring,but a ton from theese* 28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023ffa8, handle=3[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fed8, handle=3[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fe08, handle=3[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fd38, handle=3[28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE[28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fc68, handle=3 for the period. increased the files and restarted the srv, let me see what happens...any other idea, advice what settings are *needed for large amount of queries from 389ds *ldap? On Mar 28, 2011, at 4:42 PM, Rich Megginson wrote: On 03/28/2011 08:29 AM, Karoly Czovek wrote: the server is 32bit, the exact client error message is cannot connect to the server. But what is the error code?* 80?* 81?* 91?* If you can reproduce with ldapsearch, in the shell, $? should hold the error code (even ldapsearch cant). let me check the logs once appearing the errors again, now disabled the restart cronjob. On Mar 28, 2011, at 4:16 PM, Rich Megginson wrote: On 03/28/2011 03:45 AM, Karoly Czovek wrote: Hi All,* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam What version of 389-ds-base?* 32-bit or 64-bit? After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. What are the exact client error codes/messages?* Any errors in the dirsrv errors log?* Can you post excerpts of the dirsrv access log from around the time of the client errors? The 389DS has 2 cores with 2GB of ram, related settigns are the following: Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
high-rate queries
On 03/28/2011 09:09 AM, Karoly Czovek wrote:
i can reproduce, but the server is in production. if the clients got this error then i also unable to connect with ldapsearch. Ok, what is the error code? just now appeared, i have full verbose trace logs, but nothin intrestring, but a ton from theese* 28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023ffa8, handle=3 [28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fed8, handle=3 [28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fe08, handle=3 [28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fd38, handle=3 [28/Mar/2011:10:33:00 -0400] - <= slapi_reslimit_get_integer_limit() returning NO VALUE [28/Mar/2011:10:33:00 -0400] - => slapi_reslimit_get_integer_limit() conn=0xb023fc68, handle=3 What error log level are you using?* These messages are ok.* The errors log messages are going to be unhelpful at best, and misleading at worst, if you use specific log levels like CONN and TRACE, without looking at the code. for the period. increased the files and restarted the srv, let me see what happens... any other idea, advice what settings are *needed for large amount of queries from 389ds *ldap? I still don't have enough information from you to make that determination.* What version of 389-ds-base are you using?* What do you see in the access log from around the time of a failed client connection attempt, from ldapsearch or from some other client? On Mar 28, 2011, at 4:42 PM, Rich Megginson wrote: On 03/28/2011 08:29 AM, Karoly Czovek wrote: the server is 32bit, the exact client error message is cannot connect to the server. But what is the error code?* 80?* 81?* 91?* If you can reproduce with ldapsearch, in the shell, $? should hold the error code (even ldapsearch cant). let me check the logs once appearing the errors again, now disabled the restart cronjob. On Mar 28, 2011, at 4:16 PM, Rich Megginson wrote: On 03/28/2011 03:45 AM, Karoly Czovek wrote: Hi All,* Is there any reason, workaround for the 389DS about high-rate queries? Acting as LDAP server for one exim and 5 postfix servers, and for 6 courier-imap servers, libnss-pam What version of 389-ds-base?* 32-bit or 64-bit? After a time, my clients cannot connect to the 389DS, ldap queries coming back with temporary lookup faulure. What are the exact client error codes/messages?* Any errors in the dirsrv errors log?* Can you post excerpts of the dirsrv access log from around the time of the client errors? The 389DS has 2 cores with 2GB of ram, related settigns are the following: Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users --* Karoly CZOVEK Global Systems Administrator MoveOne IT Department Eastern Europe - Balkans - CIS& *Central Asia - Middle East& *Africa - Asia Pacific phone: +36 1 266 0181 - ext.6710 mobile: +36 70 708 9953 skype: mo_karoly.czovek email:*karoly.czovek@moveoneinc.com web:*http://www.moveoneinc.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
| All times are GMT. The time now is 08:59 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.