In our webmethods server DocumentStore, too many TriggerStoredata files(TriggerStoredata0000000 to TriggerStoredata0000092) are getting created. They take up lot of disk space too. What is the reason for this and can these files be deleted? What is the impact ? Appreciate your help.
Regards
The files in this subdirectory contain the locally persisted documents being processed
by Integration Server. The loss of these files will result in the loss of any persisted
documents.
Since these are related to Triggers, please verify your subscription service, it maybe trowing errors or stuckup somewhere.
For more information on subdirectories refer: http://www.idnxchange.com/webmethods-blogs/subdirectories-in-webmethods-integration-servers.html
Related
The project is an open source IDE like system to edit code, alter images,, run code, etc. for students in school.
It contains an upload of Archive/Folders which characteristics are:
Upload Archive, contains up to 30 files (txt,js,xul,xml,php, gif/png/jpg), av.size in total 500kb
Users can edit and fork
all the files are editable through Codemirror (like used on jsfiddle)
all the Gif/Png/Jpg are replaceable (10 - 40 per archive)
we expect daily at least 1'000 new uploads/forks with an average of 20 files, total-size min. 500 mb
Our enironment:
PHP
most likely MySQL database
Linux
To consider:
We don't require Searching through the folders/files on global scope
the User saved Data is as it is, never any changes from our side necessary
State-of-Development:
Ready besides the storage question and all their dependencies
Would you advise on SQL or a simple Filesystem?
Before starting the project we were 100% sure using MySQL, but with the added feature of Image modification and a growing database (atm 80/k files,2GB) we struggle. Also reading here let us hesitate too.
Advantages of MYSQL are surely the easy maintainment and simpler future restructure of the system.
Though it will get a huge database fast to search within.
By using a global php entryfile to read the Filesystem based on URL parameters, the searching can be ommitted and straight go displaying the fetched directory with its content.
We are not experienced in managing large data and rely on experience of people who faced such a situtation already.
Rather than just vote for Database or Filesystem please consider your own tips to make this environment more efficient to run (eg indexing, structure, tables, etc..) or elaborate your decision.
very thankful for any tips of you
btw, the project will be hosted at git
I believe that the best option to go is the file system taking into consideration your requirements. The pros of this choice are
Better performance of your database since the table will only hold a link to your file system where the file is stored.
It is easier to backup your database.
You have the possibility of storing the files in different locations by defining rules. This gives you a flexibility in managing your storage.
When we faced a similar problem for storing attachments in a service desk application, we have chosen to go with the filesystem. Till now everything is working as expected.
I hope that my answer is helpful to you.
I am in the process of moving our companies MediaWiki from a single server to a clustered environment. The existing file based session storage was fine with the single server, but clearly not for the cluster.
To address this I'm looking to use one of our existing MySQL database servers to handle session management but the only article I've come across is for a new MediaWiki installation.
I set $wgSessionHandler in LocalSettings.php but that had no effect.
Anyone have advice/experience with this?
This might not be the answer you're looking for, but I was just facing this issue myself.
After trying to Do The Right Thing™ for some hours, I finally gave in and just put the sessions on shared storage.
So, if you can afford to, performance wise, and have some shared storage available or can easily create some, I can only recommend just pointing PHP's session.save_path to shared storage and save yourself the trouble.
It's the easy way out. ;-)
I managed to wipe a server by mistake but PhotoRec was kind enough to recover the .frm and .myi files from the hard drive. I now have a desktop set up with the same version of MySQL to recover the data but my question is: what do I do? I have about 160 of these files. I haven't yet reinstalled the server in case I need anything else.
Also, as I'm using PhotoRec, it doesn't provide the original filenames. If this is important, how can I get the raw data out of the files and manually rebuild the database?
Edit: I managed to get ahold of the PhotoRec source and add the capability to recover the .myd files (which a bit of digging reveals to be the actual data files), but I can't get the thing to compile, and it ain't because of my mods! Can anyone help with a 'No rule to make target' error in PhotoRec? file_http.o's the culprit.
Thanks,
Rob
MYI files are useless, these are files with secondary indexes, not your data.
PhotoRec is a nice tool, I used it a lot for multimedia recovery etc. Although it claims MYD support it never worked for me. I doubt it possibly can extract MYD files.
I dont belive you can, photorec does not support MYD, im doing an attempt with ext3grep but it always segfaults.
just posting this so someone doesnt spend time better spent on using photorec for this purpose.
I know this is something of a "classic question", but does the mysql/grails (deployed on Tomcat) put a new spin on considering how to approach storage of user's uploaded files.
I like using the database for everything (simpler architecture, scaling is just scaling the database). But using the filesystem means we don't lard up mysql with binary files. Some might also argue that apache (httpd) is faster than Tomcat for serving up binary files, although I've seen numbers that actually show just putting Tomcat on the front of your site can be faster than using an apache (httpd) proxy.
How should I choose where to place user's uploaded files?
Thanks for your consideration, time and thought.
I don't know if one can make general observations about this kind of decision, since it's really down to what you are trying to do and how high up the priority list NFRs like performance and response time are to your application.
If you have lots of users, uploading lots of binary files, with a system serving large numbers of those uploaded binary files then you have a situation where the costs of storing files in the database include:
Large size binary files
Costly queries
Benefits are
Atomic commits
Scaling comes with database (though w MySQL there are some issues w multinode etc)
Less fiddly and complicated code to manage file systems etc
Given the same user situation where you store to the filesystem you will need to address
Scaling
File name management (user uploads same name file twice etc)
Creating corresponding records in DB to map to the files on disk (and the code surrounding all that)
Looking after your apache configs so they serve from the filesystem
We had a similar problem to solve as this for our Grails site where the content editors are uploading hundreds of pictures a day. We knew that driving all that demand through the application when it could be better used doing other processing was wasteful (given that the expected demand for pages was going to be in the millions per week we definitely didn't want images to cripple us).
We ended up creating upload -> file system solution. For each uploaded file a DB meta-data record was created and managed in tandem with the upload process (and conversely read that record when generating the GSP content link to the image). We served requests off disk through Apache directly based on the link requested by the browser. But, and there is always a but, remember that with things like filesystems you only have content per machine.
We had the headache of making sure images got re-synchronised onto every server, since unlike a DB which sits behind the cluster and enables the cluster behave uniformly, files are bound to physical locations on a server.
Another problem you might run up against with filesystems is folder content size. When you start having folders where there are literally tens of thousands of files in them, the folder scan at the OS level starts to really drag. To avert this problem we had to write code which managed image uploads into yyyy/MM/dd/image.name.jpg folder structures, so that no one folder accumulated hundreds of thousands of images.
What I'm implying is that while we got the performance we wanted by not using the DB for BLOB storage, that comes at the cost of development overhead and systems management.
Just as an additional suggestion: JCR (eg. Jackrabbit) - a Java Content Repository. It has several benefits when you deal with a lot of binary content. The Grails plugin isn't stable yet, but you can use Jackrabbit with the plain API.
Another thing to keep in mind is that if your site ever grows beyond one application server, you need to access the same files from all app servers. Now all app servers have access to the database, either because that's a single server or because you have a cluster. Now if you store things in the file system, you have to share that, too - maybe NFS.
Even if you upload file in filesystem, all the files get same permission, so any logged in user can access any other's file just entering the url (Since all of them get same permission). If you however plan to give each user a directory then a user permission of apache (that is what server has permission) is given to them. You should su to root, create a user and upload files to those directories. Again accessing those files could end up adding user's group to server group. If I choose to use filesystem to store binary files, is there an easier solution than this, how do you manage access to those files, corresponding to each user, and maintaining the permission? Does Spring's ACL help? Or do we have to create permission group for each user? I am totally cool with the filesystem url. My only concern is with starting a seperate process (chmod and stuff), using something like ProcessBuilder to run Operating Systems commands (or is there better solution ?). And what about permissions?
I'm not really asking whether I should use either a RDBMS or config files for 100% of my application configuration, but rather what kind of configuration is best addressed by each method.
For example, I've heard that "any kind of configuration that is not changeable by the end-user" should be in config files rather than the database. Is this accurate? How do you address configuration?
(I'm primarily concerned with many-user web applications here, but no particular platform.)
I find that during development it is of great benefit to have configuration stored in a file.
It is far easier to check out a file (web.config, app.config, or some custom file) and make changes that are instantly picked up when the code is run. There is a little more friction involved in working with configuration stored in a database. If your team uses a single development database you could easily impact other team members with your change, and if you have individual databases it takes more than a "get latest" to be up and running with the latest configuration. Also, the flexibility of XML makes it more natural to store configuration that is more than just "name-value" pairs in a file than in a relational DB.
The drawback is where you want to reuse the configuration across multiple apps or web site instances. In my own case, we have a single config file in a well-known location that can be referenced by any application.
At least, this is how we store "static" configuration that does not have to be updated by the system at runtime. User settings are probably more suited to storage in the DB.
The oneliner: As a general principle - the more likely the config data should change the better to put it into db.
The legal disclaimer:
You would need to have almost always a kind of "bootstrapping" configuration, which must be saved into a file, thus if you are using a db to store your configuration the size of the "bootrapping" conf would depend on the other great principle:
"Work smarter not harder !!!"
One thing to conside is how much config data there is, and perhaps how often it is likely to change. If the amount of data is small, then saving this in a database (if your not already using a db for anything else), would be overkill, equally maintaining a db for something that gets changed once every 6 months would probably be a waste of resources.
That said, if your already using a database for other parts of your site, then adding a table or two for configuration data is probabley not a big issue, and may fit in well with the way you are storing the rest of your data. If you already have a class for saving your data to a db, why write a new one to save to a config file.