I have Sphinx running as a Service on Windows Server 2003
I also have the ff cronjob running every 2 min to update the index:
C:\sphinx\bin\indexer.exe -c C:\sphinx\bin\sphinx.conf --rotate delta
and every 12 h:
C:\sphinx\bin\indexer.exe -c C:\sphinx\bin\sphinx.conf --rotate --all
However somehow the task every 1m ran, but there was no update on my website at all. The reindex run successfully.
The only time it update on website is to have my service restart.
What could be the problem here? I could not create a cron job to restart the service just for update. Since it could seriously affect searching operation.
Try changing the setting preopen_indexes to 0 (zero).
I had the same problem. If you run the searchd service as debug, you can see it gives a 'Broken pipe' error. This is caused because the process has his index files always open.
If you set the preopen_indexes to 0, it will only open if you search (Yes, it's a bit slower than opening it once)
I found the answer at the sphinx forum, http://sphinxsearch.com/forum/view.html?id=572
Related
I just installed Jenkins 2.46.2 on a Windows 2012 Server \o/. It runs as a system service.
I created a job that execute a windows batch (.bat) script to build a code project. This batch results in executing 2 mingw32-make.exe commands to clean and then build a full binary from source code.
Executing the batch manually on the machine, located on the same filesystem (same workspace as used by the Jenkins' job, local disk - not network disk), the clean-build takes ~50 seconds.
But when executed by Jenkins, the job takes more than 20x more time longer! (~19 minutes). It terminates succesfully with the same behavior as executed manually in cmd.exe.
I changed the launch arguments for the jvm in the jenkins.xml file with "-Xmx1024m -XX:MaxPermSize=512m" options as I have read in the documentation to improve performance. But it does not fix anything :-(
Also when I monitors the CPU/disk/RAM usages they all stay very very low while building, so I deduce that brute performances of the machine are not in cause.
Whether I invoke the batch with call statement in the Jenkins job build step or not does not change anything : the job always last 19 minutes.
Can anybody help me to investigate why so slowness ?
Thanks in advance :)
I had a similar problem. I noticed that .bat files with echo Hello World ran fast and with no problem.
But once I tried to launch any grep.exe from a batch script, it took 24 seconds (in my case) to run even with no input files. If launched manually it finishes in no time.
I used grep.exe version 2.5.4 from MSys 1.0 distribution.
The solution in my case was rather unexpected - I updated grep to version 2.24, and now, being launched from Jenkins, it takes less than one second to process over 1 MB log file.
For a couple of day investigation, I finally find the cause.
In my case, it is the reason of Jenkins agent.
When I install Jenkins agent as a windows service in the slave agent, the consuming time is so huge,but when I try to start Jenkins agent via windows command line, the consuming time is as normal as executing the batch file manually.
My env:
master: CentOS7
slave agent: win 7
And I also test this case in a slave agent of win 10 for comparison.
The time executing via Jenkins is approximately the same as executing the batch file manually on the agent machine.
So I guess this is the compatibility issue between win 7 and Jenkins.
But for that the Jenkins official said that Jenkins not support win 7 anymore (Microsoft does not support Windows 7), we temporarily put it aside.
Anyway we find a way to conquer this. Hope this will help you for similar scenario.
I installed PostgreSql on my Windows machine.
I can connect to PostgreSql through cmd.
But when I want to launch pgAdmin I am getting this error message.
Failed to connect to the pgAdmin application server. Click here to try again.
I have also Mysql installed on my machine if it can make any complications.
The same problem happened to me today:
And this is how I've solved it:
1) Use a text editor to open the config_distro.py file under the c:\Program Files\pgAdmin 4\v1\web folder. Change the value for SERVER_MODE from True to False, then save the change. (I have run Notepad++ as an Administrator, in order to be able to save in this protected folder.)
2) Go to folder c:\Users\your_name\AppData\Roaming\pgAdmin and make sure there is nothing there (delete all the files, as they are temporary and will be restored after starting pgAdmin)
3) Start pgAdmin
4) This time you will see a white box that sits - at least, on my slow laptop - about 20 seconds. (You may briefly see the original error message, but do not worry).
5) Meanwhile, the temporary files - required for running the application - are created.
6) Once the temporary files process is over, the application starts as expected.
Try starting the pgAdmin as administrator.
My config_distro.py was missing this line:
MINIFY_HTML=False
I added it as in the above steps and it works
In my case, SERVER_MODE was already False in config_distro.py. I then proceeded to start pgadmin4 as an administrator. This also did not work. Finally, I resolved this by restarting postgresql service in services.msc.
postgres service restart
In my case, the problem was non-ascii username.
Find pgAdmin installation and open/create config_local.py in editor, add this:
DATA_DIR = "C:/Data/pgAdmin" # set non-ascii path here
and run setup.py using python interpreter.
You can start the server manually - any errors will echo on the terminal. The windows app seems touchy on timing - this allows the server to take as much time as needed to start up.
Assuming you installed version 3 into "p:\pgAdmin 4" run the following commands"
p:
cd "\pgAdmin 4\v3\web"
set PYTHONPATH=P:\pgAdmin 4\v3\venv\Lib;P:\pgAdmin 4\v3\venv\DLLs
python pgAdmin4.py
When I run that I get the following output:
Starting pgAdmin 4. Please navigate to http://127.0.0.1:5050 in your browser.
I ran into this today even though the service was running in Windows 10. I just stopped the service, gave it a few seconds, and restarted it. I was able to connect with pgAdmin 4.
In my case the problem was solved by restarting the postgresql service.
Windows-> Service -> find for postgreSQL -> Stop and then Start
I have been trying to configure regular automated backups to a shared network drive using the Windows Server Backup console. When I backup manually, it works, however it does not run on its own as scheduled. I have made sure to enable run backup while not logged in. There are no error messages when it does not run according to schedule, it just skips to logging the next scheduled backup as the next day.
I have also tried using the wbadmin command line. My script is similar to the following:
wbadmin enable backup –addtarget:\backupshare\myshare –include: c:\ –user:DOMAIN\mylogin –password:mypassword –schedule:19:00 -systemState -quiet -allowDeleteOldBackups -
I have not received any errors with my script and the windows command line acknowledges that there is a scheduled backup to run. However, the backup does not run and when I check wbadmin get status at the time it is scheduled, it will tell me there is no back up running at the moment with no error codes.
I am not sure why my back ups will not run as scheduled as they will run manually.
Any help would be greatly appreciated,
Thanks!
I’m going to assume that you’re running it with heightened privileges and for running the task you’re using a Domain Admin account, I would suggest running the command manually from command line and add in this argument “get status > \task.log”
I downloaded 64-bit zipped version of mongodb for windows, created '/data/db' as instructed.
Now, when I run "mongod" command, I am getting the following error & the mongodb server shuts down automatically.
"ERROR : listen() failed error-10013. An attempt was made to access socket in a way forbidden by its access permissions. "
Please help me to clear the firewall settings in windows to prevent this error & run mongodb.
I was able to fix the error by using the following command : "mongod --bind_ip="127.0.0.1". :)
This error also seems to happen when mongod is already running. On Windows 10, mongod will be listed under Background Processes in the Task Manager if it is running. If it is already running, ending the task should allow you to run mongod again without this error occurring. Also check that it is not running as a service; it may be set to restart automatically.
Also, if you have a docker container running mongodb, you also get this error. If you stop your container(s) running mongodb, then it should start up.
I was able to fix this issue by allowing access for Mongo Db Server Application under firewall settings in my antivirus settings.
After you did the above step,open the cmd as administrator and go to the bin path of mongodb application in your system.
Then run the below command.
mongod
Note : try the above steps only after you tried the below steps
1) https://docs.mongodb.com/manual/tutorial/configure-windows-netsh-firewall/
2)https://www.tomshardware.com/news/how-to-open-firewall-ports-in-windows-10,36451.html
I ran across a similar error which is why I ended up on this thread. For me, my solution was that McAfee Antivirus was blocking MongoDB.
The initial error basically showed that access was denied for mongo:
mongo error
I was able to do a search on the internet and found steps to allow MongoDB to run under McAfee Antivirus software by changing the setting for the app directly.
mcaffee settings
When I located MongoDB in the apps requesting internet access, it was initially set to blocked. I selected the app, clicked on edit and changed it to 'Designated ports'.
mongodb settings changed
Now, I am able to run mongo whether the mongod service is started automatically or if I start it manually in a hyper terminal window.
I've reindexed my Sphinx search with /usr/local/sphinx/bin/indexer --all --rotate and renamed my original index output files to something else. Simply changing the index argument passed to $sphinx->Query($query, $index); returns no results.
I suspected the daemon doesn't know the new index files exist. So I ran
sudo /usr/local/sphinx/bin/searchd
again to try to restart it. But it threw
FATAL: failed to lock pid file '/usr/local/sphinx/var/log/searchd.pid': Resource temporarily unavailable (searchd already running?)
I had to kill the 2 processes of the search daemon and start it again to grab from the new index files. Is there a graceful way to restart it?
I know this is a late answer, but just so you know, to 'restart' Sphinx, you need to stop it then start it (as in, two distinct processes).
To stop it, call searchd --stop then just start it again with searchd.
You'll need to call indexer on the new index to create it and then --rotate to update it.
So it would be something like
indexer --config /path/to/config.conf indexname
And then when you just want to update your indexes
indexer --config /path/to/config.conf --rotate --all
This will create a temporary copy of each index and replace the old ones when finished.
For more info on what actually happens see http://sphinxsearch.com/docs/manual-0.9.9.html#ref-indexer
On the other error your getting
Do
ps aux | grep searchd
if it returns no results, then remove /usr/local/sphinx/var/log/searchd.pid
and start searchd again
It seems there is an issue with the searchd --stop command failing to stop the daemon on some instances of Sphinx.
Try: service sphinxsearch stop
See: https://bugs.launchpad.net/ubuntu/+source/sphinxsearch/+bug/990395
service searchd start worked for me on CentOS